Your first check

Start with one address

Paste your project URL into the first look. I ask for the page response and domain signals there. If the page arrives empty and a script fills it in, I also open it once in a browser and show you what I saw there. If I can't open it just then, the result says so. For a page I could read, I also show what a link to it looks like when shared: its title, its summary and whether its preview picture answered. I don't load that picture for you to see. Create your account to keep the result and open the project. I then prepare suggested checks in the background. A suggestion is a starting point, not a saved result or an incident.

You can open the project while I prepare those suggestions. If setup is still working, come back to its progress from the project. If it says it stopped, use the retry offered there. You can also make a check yourself; an empty check list while setup runs does not mean the project has been checked. When you add a project, I say while you type if you already watch that address, and if none of the suggestions passed, Try again runs the ones that didn't pass once more, at most once every 10 minutes.

If setup says Cookie notice needs your help, choose Open cookie setup. In project settings, under Before I check, choose Show me what to do to record how you dismiss the notice. Recording needs a desktop browser. Once you verify and save that recording, I continue preparing the suggested checks. An unfinished cookie setup cannot be skipped by retrying preparation.

You can also set up cookie notice handling yourself in project settings, under Before I check → Cookie notice → Show me what to do, even if I did not find a notice during setup. Verify and save the recording before I use it for your checks.

Once my browser has finished its first run of your home page, the setup screen shows the picture it took there and marks where the checks I kept start. A check that starts on another page is marked on the link of your home page that leads there.

When your site doesn’t let my browser in

Some sites turn my browser away before it sees anything: a firewall, bot protection, a rule for your country or a rate limit. When your home page answers 403, 429 or 451, or a 503 that shows a challenge page, I say your site didn't let me in — never that it is broken.

The same can happen on a later run. A run that was turned away is not a failure: it doesn't move the failure count and never sends an alert. The check shows as unknown (○) in the project, with a link to the steps to let me in. After two such runs in a row I send one email; see when the fault is mine.

The steps are for Cloudflare or Vercel when your site's answer names one, and general instructions for your host otherwise. They list the addresses I visit from; when I have none published, they stay general.

If a firewall or bot protection keeps me out, How to recognise my browser on the abuse page lists the addresses I visit from and the name my browser carries, so you can let me in.

Once you've let me in, press I let you in, check again on the setup screen. I look at your home page again, and if it lets me in, I finish setting up the project. You can press it 3 times an hour and 10 times a day for each project. I don't retry on my own.

Record a safe public path

In the project, choose to add a check and open the browser. For a shop, start with its public catalog: load the home page, follow a link to the catalog, then mark words you expect to see on that page while recording. Finish recording and give the check a name you will recognise. You do not need to create an order or an account on the shop to make this first check.

Replay it in a clean browser to see whether those steps work without your current session. A replay proves this draft can work; it is not a stored check run. If you save without a replay, I queue a first run right away; a check that passed its clean replay follows its daily or deploy schedule. The saved result appears in the project and run history once that run finishes, with evidence you can open. An incident is a separate state reached only after the same check fails twice in a row. See how alerts work.

Record a safe signed-in path

This recipe is for a username and password form on a site you control. Keep its sign-in page and account page on the same origin: the same scheme, hostname and port. For example, use your own sign-in page and account page on that one site.

1. First verify the project's domain under Domain ownership in Project settings. Create a separate restricted account with only the access needed to read the result you want to check. Do not use an admin account.
2. Under Before I check, Saved values are inputs kept for this project, not a saved starting state or session. Store a value first and pick it while recording, or type it while recording and it is sealed when you save. I never show a saved value back; when you replace one, re-record the setup that uses it. A stored password alone does not create sign-in steps.
3. Give the setup a Name and confirm Page I open first before choosing Set up sign-in. The address starts as your project's address; change it to your same-origin sign-in page if needed. Browser password is HTTP Basic auth, sent before a page loads. It is separate from signing in through your application's form.
4. Recording needs a desktop browser. In the remote recording browser, sign in with that restricted account and keep the setup minimal. Finish recording, acknowledge that the actions may repeat before every check using it, then replay in a clean browser. Save only after the setup says This setup worked in a clean browser. That proves the recorded setup replayed, not that I independently validated your password.
5. Open an existing saved check's editor and choose this project's named starting state in Starts from before recording or re-recording the read-only journey. Wait for the saving feedback to succeed; if it is refused, read that message before continuing. This choice saves there, separately from Save changes. It prepares clean replay and later runs; it is not a step in the check.
6. The remote browser where you record is separate from the clean replay browser and your own logged-in tab. Choosing Starts from does not instantly sign in that recording browser; you may need to sign in there yourself before the protected page opens. Your local cookies are not uploaded. Record a read-only outcome, such as opening the account page and marking expected words. Replay in a clean browser, then save. A draft replay is not a stored ordinary result: open the later run in the project and run history to see its evidence.

If the username or password is wrong, check that restricted account on your own site, store the corrected Saved value, then re-record the setup and replay clean again. When re-recording, confirm the page actually opened; the previous sign-in address is not automatically restored.

If ownership is refused, verify Domain ownership in Project settings and keep the public path meanwhile. A path that continues to a second site outside the project's domain still cannot run after verification. If my browser is turned away, follow the steps to let me in, including the published addresses and I let you in, check again. Refused access does not mean your app is broken.

If replay fails, its result is uncertain, or the starting state is unavailable, read the step or setup result, correct or re-record the setup and replay again. Until the setup is ready and a dependent check has real evidence, do not treat that check as verified.

OAuth, external identity redirects, MFA or one-time codes, passkeys and challenge flows are outside this recipe. If this username/password path cannot replay, start with the public path. Repeated actions can change your site: keep the journey read-only and avoid production purchases, destructive actions and privileged accounts. I do not automatically clean up or undo those actions.

When you need domain ownership

A read-only path through public pages can run without proving ownership. Checks that fill forms or read email wait until you verify the project's domain under Domain ownership in Project settings. A path that continues to a second site outside that domain cannot run even after verification. You can keep the public catalog check while deciding whether to verify the protected path; the public path does not need your DNS or a file on your site.