Glossary
Uptime monitoring
Uptime monitoring is the practice of requesting a site from outside, on a schedule, and recording whether it answered. Its value is entirely in the word outside: a service can be healthy by every internal measure and unreachable because of DNS, a certificate, a firewall rule or a routing problem between it and its users. The most common mistake in setting it up is treating a 200 response as proof that the page works.
What a check can actually establish
That the name resolved, which rules out a whole class of DNS failures.
That a connection was established and the certificate validated, which catches an expiry before a customer does.
That a response came back, and how long it took.
That the response had the expected status — and, if configured, that the body contains something it should.
The last of those is what separates monitoring from a heartbeat. A page can answer 200 with an error rendered inside it, and only content matching notices.
Why one check location is not enough
A single vantage point cannot distinguish your site being down from the path between it and one location being down.
Which produces the two failure modes that destroy trust in an alert: a page that is up alerting because one network had a problem, and a regional outage going unnoticed because the checker is elsewhere.
Checking from several locations and requiring agreement before alerting removes most of both.
It also makes a genuinely regional problem visible as one, which is information a single location cannot produce at all.
Frequency, and what it costs
The interval is the floor on how long an outage can go unnoticed, so a five-minute interval means up to five minutes of unnoticed downtime.
Shorter intervals cost requests against your own infrastructure, which is negligible for a status route and not negligible for a heavy page.
Which is one argument for monitoring a dedicated lightweight endpoint rather than the home page — and one argument against, since the home page is what visitors actually load.
Most services do both: a frequent check on a light route and a less frequent one on a real page.
What is observable from outside
Whether public monitoring tooling is referenced by the site, and whether a public status page exists.
Whether the site currently answers, how quickly, and whether a maintenance page is being served.
Whether the site is served from more than one region, which bears on how an outage would present.
Not your monitoring configuration, and not your history — a single scan is one observation, not a record.
What it does not cover
Whether the pages behind the login work, since a check runs anonymously.
Whether a transaction completes, unless a scripted flow is configured rather than a single request.
Whether the site is slow, as opposed to down — a response that arrives in eight seconds is still a response.
Whether the content is correct, which is why matching on expected text is worth configuring on the routes that matter.
Frequently asked questions
- Is a 200 response enough to say a page is working?
- No. A page can answer 200 while rendering an error, an empty state or a maintenance notice. Matching on expected content is what turns a heartbeat into monitoring.
- How often should a check run?
- The interval is the maximum time an outage can go unnoticed. A minute is common for a light status route; a heavy page usually gets a longer interval.
- Why do I get alerts when my site is clearly up?
- Usually a single check location seeing a network problem on its own path. Requiring agreement between several locations before alerting removes most false alarms.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website