Uptime monitoring is often described as a repeated request to a web address. That is correct, but incomplete. The useful outcome is not the request itself. It is an operational signal that helps the right person decide whether a service is unavailable, degraded or merely reporting a transient fault.
An uptime check asks a defined question from a defined location at a defined interval, then applies a rule to the response. It does not prove that every visitor, page or transaction is working.
What an uptime check actually proves
A basic HTTP check can confirm that a network path reached an endpoint and received a response. The response status, timing and optional content rule provide more context. A 200 response can still contain an application error, an empty template or a cached maintenance page, so the status code should not be treated as the whole result.
Define the question before configuring the monitor. “Is the server up?” is vague. “Does the public checkout page return an expected success status and contain the current checkout marker within ten seconds?” is testable.
- Identify the exact service or journey being protected.
- Choose the smallest check that can detect the relevant failure.
- State what a pass does and does not prove.
- Assign an owner before the first alert is enabled.
Layer the checks instead of duplicating them
Separate monitors should cover separate failure modes. DNS resolution, certificate validity, HTTP status, expected page content and a browser journey answer different questions. Running several identical homepage checks at slightly different intervals adds cost and noise without adding much diagnostic value.
| Layer | Question | Typical blind spot |
|---|---|---|
| DNS | Does the hostname resolve as expected? | The resolved service may still fail. |
| TLS certificate | Is the presented certificate trusted, in date and valid for the hostname? | The application behind HTTPS may be broken. |
| HTTP | Does an endpoint return an acceptable response? | A successful shell can contain wrong content. |
| Keyword or content | Does the response contain a stable expected marker? | It may not exercise client-side behaviour. |
| Browser journey | Can a user-like sequence complete? | More moving parts can increase false alarms. |
Confirm before escalating
One failed probe is evidence, not yet a diagnosis. A practical confirmation policy can retry from the same location, check from a second location, or require a defined number of failures before opening an incident. The right balance depends on the service and the harm caused by a slow or false alert.
Maintenance windows should suppress expected notifications without erasing the underlying record. Recovery rules also matter. A single success after a long outage may not be enough to close an incident if caches, databases or queues are still recovering.
Route useful alerts
Every alert should carry enough context to start triage: the affected client or service, check type, first failure time, confirmation state, latest response and the runbook owner. Avoid sending every event to every person. Use severity and service ownership to decide whether an event belongs in email, chat, an on-call route or a client communication process.
More recipients do not create more ownership. An alert with no named responder and no next action becomes background noise.
Verify recovery as deliberately as failure
Recovery should be tested against the same success rule that defined normal service. If the incident affected a transaction, confirm the transaction rather than closing it because the homepage loads. Record the recovery time separately from the first successful probe when a human validation step is required.
For client communication, distinguish “monitor has recovered” from “service is fully restored” when those are not the same state.
A starter monitoring policy
- List the small set of client journeys that justify an immediate response.
- Add lower-cost checks for DNS, TLS and HTTP to improve diagnosis.
- Set confirmation and maintenance rules before enabling notifications.
- Give each service an owner and one documented first response.
- Review false positives, missed incidents and stale monitors monthly.
That policy is deliberately product-neutral. Once the questions and response rules are defined, a product comparison can measure whether a tool supports the workflow instead of copying feature tables.
Primary references
- RFC 9110: HTTP Semantics, the standards reference for HTTP status semantics.
- Google Site Reliability Engineering: Monitoring Distributed Systems, including guidance on actionable signals and alert design.
- MDN: HTTP response status codes, a practical reference to the response classes used in endpoint checks.