Uptime is green and signup is broken

A 200 only means the server answered

Most uptime monitors request a URL and look at the status code. Some also search the HTML for a word. That is a useful alarm for a server that is down, a DNS record that disappeared, or a certificate that expired. It is a weak alarm for a signup form. The host can return HTTP 200, and the form can still do nothing when a person clicks it.

Single-page apps make this worse. The server often sends the same index.html for / and for /signup. The monitor sees 200 and the word from your title tag, and it marks the check green. The JavaScript that mounts the form, the request the form sends, and the text you show after success are never executed. A broken deploy looks healthy for as long as the HTML file is served.

What the monitor never does

It does not wait for the app to finish booting. A page that paints a shell and then throws in an effect is still a pass if the HTML arrived quickly. It does not click Create account. It does not type a test email. It does not notice that the button is covered, disabled, or wired to a function that no longer exists.

It does not follow the request the click was supposed to make. Signup usually fails one step later: the auth call returns 400 because the redirect URL is not allowed, the API returns 500, or the success screen expects the words 'Welcome back' and the new screen says something else. None of that is visible in the first HTML response. A keyword check for a word that sits in the template, not in the result of the click, stays green too.

It also does not tell you what to change. A red uptime row says the URL failed. A broken signup needs the step, the text that was expected, and the text that showed up. Without that, you reproduce it by hand after a customer writes in.

What a synthetic flow check is

A synthetic check is a browser that follows a script on a schedule, the way a customer would, and fails when a step does not happen. The script is small on purpose. Open this URL. Click this button. Type this test value. Expect this sentence to be on the page. If the sentence is missing, the check fails, even though the server returned 200 at the start.

It is not a load test, and it is not a security audit. One browser, on a timer, walks one path. That is enough to catch the class of bug uptime misses: the deploy that shipped, the page that opens, and the task that no longer completes. You still want an uptime check for the outage where nothing answers. You want the flow check for the outage where the homepage looks normal.

How to set one up in WhoopsBot

Create an account and add a flow. Name it for the path, not for the page. 'Signup still works' is a better name than 'homepage'. Write the steps the way you would tell a teammate. Visit the published signup URL, not the preview. Click the control labeled Create account. Fill the email and password with a test inbox you control. Expect a sentence that only appears when signup succeeded. 'Welcome back' is a fine expectation if that is the real copy. A sentence that also appears on the logged-out page is not, because the check would pass when the click did nothing.

Use a test account, not a customer's. The flow will type and click, because you asked it to. The free launch check is different: that one only looks at a single page and does not submit forms. Do not point a flow at a real person's data. If signup sends a confirmation email, Starter and Pro can include an email-arrival step. The free plan does not.

Save it. The free plan runs one flow once a day and leaves the result on the run page. There is no email on that plan. Starter runs up to five flows every six hours, emails you when a flow starts failing, and sends a weekly report. Pro runs up to twenty flows every hour and emails on every failure. Prices are $0, $19 USD per month, and $49 USD per month. You can cancel from Billing. The first payment is refunded in full if you ask within 14 days.

How to read a failure

A failed run names the step and says what it expected to see. That is the whole point of the sentence you chose. If the run says it did not see 'Welcome back', open the screenshot on the run and compare it with the page you have now. The usual causes are the ones on a fresh publish: the button label changed, the success copy changed, the auth redirect URL does not include this origin, or the client bundle is calling the wrong project.

The run also offers a fix prompt you can paste into Cursor or Lovable. The prompt is a description of the failure, not a patch. Read it, then look at the page. If the expectation was wrong, edit the flow. A check that fails because you renamed the heading is noise, and noise is how people start ignoring alarms.

What to keep beside it

Leave the uptime monitor in place for 'the site does not answer'. Add the flow for 'a person cannot finish signup'. If you only have time for one flow, make it the path that creates an account or takes payment. Those are the breaks that do not show up as a 500 on the homepage.

Before you wire the schedule, paste the published URL into the free check once. It will tell you if that first page fails to load, throws in the console, ships an obvious secret, or is missing the usual security headers. Then let the flow watch the click. The green light you want is the one that only stays on when the sentence after signup is actually there.