Uptime is green but checkout is broken

An uptime monitor requests a URL and checks the status code. That answers "is the process running?" It does not answer "can a new person create an account and reach Stripe?"

Those are different failures, and AI-built apps hit the second one more often. A prompt that renames a button, gates the dashboard on a flag that is never set, or points the upgrade link at a deleted route still returns 200 for /.

What a green check can hide

• Signup posts to an action that throws after the client already showed a success toast.
• The verification email is sent from an unverified domain and never arrives.
• Login sets a cookie on the wrong domain.
• The upgrade button links to /billing which now redirects to /.
• Checkout opens, but only for accounts that already have a Stripe customer, so your own test user sails through and a new one does not.
• A paid page renders the product for anyone with a session cookie.

None of that fails GET /.

What to assert instead

Walk the path with a browser and a brand new inbox:

1. The signup form is visible and submits.
2. If the product sends mail, the message arrives and its link opens.
3. The new account can log in.
4. A checkout control reaches Stripe Checkout or your card form.
5. Nobody enters a card.
6. A page that should be paid stays locked for that account.

That is the check SignupCanary runs. Keep an uptime monitor too if you want to know the host is down. They are not substitutes.

When the homepage hash is not enough

Pro and Agency plans hash the public HTML on the daily run and check immediately when a deploy hook fires. A hash change means the bytes changed. It does not mean signup works. The browser check is what catches a broken form, including on a homepage whose bytes did not change.