What it measures
Whether a request from a given location, at a given moment, got a response that met the rule: a status code, a time limit and perhaps expected text. It is a statement about the path from the monitor to the site as much as about the site.
What it misses
A page that returns 200 with an error message unless text is checked, a broken checkout behind a single page check, anything that happens between checks and problems inside the server. A probe can also be blind to the certificate: Amazon’s Route 53 documentation notes that its HTTPS health checks “don’t validate SSL/TLS certificates, so checks don’t fail if a certificate is invalid or expired”. Scheduled jobs need a different kind of monitor.
Making it trustworthy
Confirming a failure from a second location, requiring several failures, setting sensible timeouts and treating periods with no measurement as unknown rather than up all reduce false alarms and false comfort.
An example rule
GET https://www.example.com/ every minute from two regions. Success: status 200 within 10 seconds and the page contains the text “Add to basket”. Down: both regions fail. One region failing is a regional issue. A minute with no valid measurement is unknown, not up. Written like this, the rule can be explained to a client in four lines and checked later against the stored results.
What to check
What the monitor counts as success, how often and from where it checks, how failures are confirmed and how gaps are reported.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.