HTTP 200 is not a working product
Uptime checks request one URL and look at the status code, sometimes a keyword. The page they were given is almost always the homepage. Signup, login, and checkout are other routes, other buttons, and often other origins (Stripe, a Supabase function, a webhook). Any of those can break while the homepage keeps returning 200 in under a second.
The stories are dull and expensive: a publish drops /checkout, a webhook secret rotates, a free-trial form posts to a function that 500s. The team hears about it from a customer days later. The status page never changed.
Check the path a customer takes
You want a browser to open the live site, follow Sign up, follow Log in, and open checkout, then stop. Stopping matters. A synthetic user that clicks Pay will create charges, send receipts, and page you for a test you scheduled.
Heedza records those paths the first time it can see them, then replays the navigation. A checkout run ends when the payment form or the pay button is on screen. The email you get on failure has a screenshot and a prompt aimed at the tool you build with, such as Lovable, Cursor, Claude, or ChatGPT, because that is where the fix will actually be typed.
What this will not catch
A check that stops before Pay will not notice a Stripe webhook that fails after a real charge. It will not notice an email provider rejecting your magic links. It will not log into an account unless you later add a test user, which this version does not do. It will notice the page being gone, the form being gone, and the site not loading. That is the failure mode people actually miss.
Run it on a schedule that matches how often you publish. Daily is enough for a side project. Hourly is enough when a broken checkout costs a sale. Every 15 minutes is for a stack of client apps.