We already made the case that a 200 can still mean down. This is the practical half: how to configure checks so that class of failure pages you.
Failure modes that return 200
- CDN or host default park page
- App error shell that still says OK
- "Maintenance" HTML served on purpose with 200
- Empty SPA shell while the API is dead (if you only hit the static host)
- Wrong vhost / leftover staging banner on the production hostname
Status code checks alone call these healthy.
What to assert
Must include: a token that only the real product returns: app name in a stable footer, "status":"ok" from /health, a known login form marker.
Must not include: Parked Domain, Error, Cloudflare, or whatever your failure pages say. Pick strings that are stable.
Keep markers boring. Marketing copy that changes every campaign will false-alert you.
Where to point the monitor
Best: a health endpoint designed for machines.
Good: login page with a stable marker.
Risky: homepage with weekly hero experiments.
If you monitor the SPA origin, also monitor the API the SPA needs, or accept that you are only watching half the product.
Confirmation still matters
A content mismatch from one region can be a bad cache POP. Prefer multi-region agreement before you wake someone, same as with status failures.
Tallwatch ships keyword checks and HTTP Smart Checks — body contains / not-contains, regex, JSON path, headers, and latency — then pages only when at least two regions agree. If you are still on a status-only tool, watch the best status+latency URL you can and put the known 200-lie modes in the runbook until you move. Do not pretend a status-only check covers soft failures.
Keyword checks are not cleverness. They are admitting that HTTP status was always a lossy summary of "can a human use this."
