Guides / Monitoring
Monitoring
A user opens your site and gets a full-page "Something went wrong. Please try again later." Your monitor, checking the same URL at the same moment, reports everything healthy: HTTP 200, fast response, green row in the history. Both are telling the truth. The server did successfully deliver a document. The document just happens to be an apology.
The status code describes the transaction, not the content. A 200 means "I received your request and returned a response," and the server has no opinion about whether that response is your product or an error screen wearing your CSS. Anything that renders a page, including a page that says everything is broken, can render it with a healthy status code, and a monitor that only reads the code will bless it every time.
The fix is content assertion: the monitor reads the response body and applies a rule to the text. Two rules cover nearly everything, and they point in opposite directions:
| Rule | Fails when | Catches |
|---|---|---|
| Keyword must be present | expected text is missing from the body | blank pages, half-rendered pages, wrong content, parked domains |
| Keyword must be absent | forbidden text appears in the body | your own error page's copy, framework fallback screens, cached errors |
Picking the keywords is the whole craft, and it's mostly about choosing text that's stable:
A failed content check is an ordinary failure to everything downstream: it counts toward the retry threshold, opens an incident, and climbs the escalation chain until someone acknowledges. The response arriving quickly with a green status code changes nothing, because the check failed on what the page actually said.
Create an HTTP monitor for the page, then add a content assertion alongside the status check: a keyword that must be present, one that must be absent, or both. Start with your homepage and the two or three pages where an unnoticed error costs the most, your signup and checkout being the usual suspects. Thirty seconds per monitor, and the class of outage where the server smiles while the page apologizes stops being invisible.
HTTP 200 means the server delivered a document, not that the document is your working site. Error handlers, failed SPA boots, mismatched deploys, and stale caches all ship broken pages under healthy codes, and a status-code monitor blesses every one of them. Assert on the content instead: text that must be there, taken from your page's stable furniture, and text that must never be there, taken word for word from your own error screen. Then a page that says "something went wrong" fails like the outage it is.
failover.io reads the response body as well as the status code, then escalates until someone acknowledges. Free plan, no credit card.
Start monitoring free →