Your uptime monitor is green. Your users are emailing you screenshots of a blank page. Both are right — because a naive uptime check only asks "did the server answer?", and the server answered 200 while serving garbage.
How a healthy status code hides a broken page
Modern stacks make 200-with-nothing surprisingly common. A single-page app returns its shell with a 200 and then fails to fetch data client-side. A reverse proxy serves a cached maintenance page at 200. An API returns {"error": "..."} with a 200 because someone forgot to set the status. A CDN serves a stale 200 while the origin is down. In every case the HTTP layer looks perfect and the page is useless.
The fix: assert on content, not just status
Layer two cheap checks on top of the status code:
- Expected status: require an exact code (e.g. 200), so a stealth redirect to a login or error page is caught.
- Keyword match: require a string that only appears when the page truly rendered — a product name in the footer, a specific button label, a JSON field like
"status":"ok". If the keyword is missing, the check fails even on a 200.
curl https://notdown.notdown-app.workers.dev/api/monitors -H "Authorization: Bearer $TOKEN" \
-H "content-type: application/json" \
-d '{"type":"http","name":"Store","target":"https://example.com",
"expect_status":200,"expect_keyword":"Add to cart"}'
Now "up" means the server answered 200 and the page actually contains the thing that proves it works — a far stronger guarantee than a status code alone.
Pick a keyword that fails when the app fails
The art is choosing a string that is present only on the genuinely-working page. Good picks: text rendered from your database (proves the DB is reachable), a value from a downstream API (proves the integration works), or a specific element that only appears post-login for authenticated checks. Bad picks: text in the static HTML shell or the <title>, which render even when everything behind them is broken.
Watch for the change, too
Sometimes "broken" means "changed unexpectedly" — a price that shouldn't have moved, a docs page that was silently edited, a config endpoint that flipped. Content-change monitoring captures a text baseline and alerts you with a diff when it shifts, which is a different question from "is it up" but often the one you actually care about.
The rule
"Responds" and "works" are different claims. Monitor the second one. A status code tells you the front door opened; a keyword assertion tells you the lights are on inside.
NotDown supports exact-status and keyword assertions on every HTTP monitor, plus page-change monitoring with diffs — all free. Start monitoring →