How GlitchNanny checks work

Every check is a real HTTP request from our servers to your public app. We never log in to your app, create accounts in it or make payments.

Fail on HTTP 4xx/5xx, timeouts (12s), DNS or SSL errors.
Fail on known error screens: Next.js "Application error", Vercel "deployment not found / paused / function crashed", Cloudflare errors, "Internal Server Error", paused backend projects.
Optional "must contain text" rule catches blank or broken pages, for example requiring "Sign in" on your log-in page.
Limit: apps that render everything in the browser (single-page apps) may return the same shell for every URL. Use the "must contain" rule with text from the server-rendered HTML, or rely on the error-screen detection.

We POST an unsigned test event. A healthy handler rejects it with HTTP 400 (bad or missing signature). That proves the route exists, accepts POST, and your code runs.
We flag 404/410 (route gone), 405 (no POST), 401/403 (auth or deployment protection blocking Stripe), 3xx (Stripe will not follow redirects), 5xx (handler crashing), and HTML pages (wrong URL).
Limit: this does not prove Stripe is delivering real events to you or that your handler processes them correctly. Reading delivery failures from your Stripe account is on the roadmap.

Before alerting we retry once a few seconds later. You get one email when a check breaks and one when it recovers, plus a weekly report every Monday.

An AI browser agent that actually clicks through sign-up, log-in and a test checkout, with screenshots on failure.