How to check that a login or checkout flow still works
Run a real browser through your sign-in or checkout on a schedule, and get a screenshot of the step that broke before customers report it.
Check what users do · 4 min read · Updated Oct 12, 2026
The home page loads. The uptime check is green. And for the last two hours nobody has been able to sign in, because a deploy renamed a form field, or a script from a third party stopped loading, or the session cookie is being set for the wrong domain.
An uptime check asks one question: does this address answer? Sign-in and checkout are a sequence of pages, scripts and redirects, and they break in the middle. To know they work, something has to go through them.
How it works
A browser check, also called a synthetic check, drives a real browser through a journey the way a customer would: open the page, type into fields, click, wait for what comes next. Each step either happens or it does not. The check runs on a schedule, and when a step fails you are told which one, with a picture of what the browser saw.
It is slower and heavier than an uptime check, so it is for the few journeys the business depends on.
Step 1: Choose the journeys worth checking
Each journey needs upkeep when the product changes, so pick by what a failure costs:
- Signing in. If it breaks, every existing customer is locked out.
- Signing up. If it breaks, you get no new ones and nobody complains.
- Paying. If it breaks, you lose money by the minute.
Two or three journeys is a good number. Leave the rest to ordinary uptime checks.
Step 2: Create an account for the check
The check needs to sign in as someone. Make that someone on purpose.
- A dedicated test account, never a real customer's and never an administrator's.
- The least access that still lets it sign in and reach the page you assert on.
- No two-factor step, because a scheduled browser cannot answer one. If your product requires it, exempt this one account.
- No CAPTCHA. A browser check cannot solve one, and should not. Exempt the account, or the address the check comes from.
Step 3: Write the journey, ending in proof
A journey is a short list of actions, each aimed at an element on the page:
| Step | Action | Target | Value |
|---|---|---|---|
| 1 | Open | https://app.example.com/login | |
| 2 | Type | input[name="email"] | monitor@example.com |
| 3 | Type | input[name="password"] | the test account's password |
| 4 | Click | button[type="submit"] | |
| 5 | Expect the address | /dashboard | |
| 6 | Expect text | h1 | Dashboard |
The last two steps are what make this a test. Without them, a journey that only clicks will "pass" on an error page. Check the address the browser ended up at, and check that the page shows what it should.
Choose selectors that survive a redesign. A class such as .btn-blue-lg changes with the next one. Prefer name, id, or an attribute added for testing.
Keep the password out of the steps. Any tool worth using stores it as a secret that the steps refer to by name.
Step 4: For a checkout, decide where to stop
The check must never place a real order.
- Stop before payment. Add to cart, go to checkout, fill in the address, and end by expecting the payment form. This covers most of what breaks.
- Or pay in test mode. If your payment provider has a test mode with test card numbers and your product can be reached in that mode, run the whole journey there.
Step 5: Test the failure
- Run the journey once and see every step pass.
- Change the last expectation to text that is not on the page. The run should fail at that step, show you the page as the browser saw it, and reach a person.
- Put the right text back.
Allow one retry before a run counts as failed. A single slow page load is not an outage.
Common mistakes
- No assertion at the end. The journey passes on an error page.
- Using a real account. A leaked or locked test account is an inconvenience. A leaked administrator password is an incident.
- Selectors that depend on styling. They break on the next redesign and the alert is ignored.
- Checking too many journeys. Cover what earns or keeps revenue.
- Running it from one place only. A network problem near the checker looks like a broken sign-in.
Doing this in saysOK
saysOK calls these synthetic checks. They run in a real Chromium browser, and a check is a list of steps: Go to URL, Fill field, Click, Wait for element, Expect text, Expect URL and Take screenshot. A password is saved once as a secret and used in a Fill field step as env.NAME.
A failed run is retried before it counts, and with more than one region ticked you choose how many must see the failure. When a step fails you get a screenshot of it, the step's error, and by default a video of the run. An incident opens and your workspace's channels are told.
Synthetic checks are not in every plan; see pricing.
Next
A browser check answers "can customers use it?". Keep the cheaper checks beside it for "is it reachable?" and "is anything about to expire?": monitor an API endpoint and get alerted before an SSL certificate expires.
Set this up in saysOK
Start on the free plan. The guide says where a step needs a paid one.