What uptime monitoring measures
Uptime monitoring checks, on a schedule and from outside your network, whether a service responds the way you expect. A monitoring service sends a request every minute or few minutes and compares the result with an expected status code, word or open port. When checks keep failing, it alerts someone.
Uptime is the share of time, or of checks, in which the service passed over a period such as 30 days. Because the checks imitate a user from outside, this is also called synthetic or black-box monitoring.
The result reflects the checker's point of view. It can show that your homepage returned 200 from three regions. A check from outside can't show that checkout works for a signed-in user or that a background job ran, which takes application metrics and logs.
Types of uptime checks
Each check type catches a different kind of failure, so most setups combine a few.
- HTTP status check: requests a URL and expects a status code, usually 200, within a timeout. It also catches DNS, TLS and connection failures on the way.
- Keyword check: also looks for a word or phrase in the response body, or for its absence. It catches pages that return 200 but show an error or an empty template.
- TCP port check: opens a connection to a host and port, such as 443 for HTTPS or 25 for SMTP. It confirms the service accepts connections but doesn't test its replies.
- DNS check: resolves a hostname and compares the answer with the records you expect. It catches deleted records, wrong values and lapsed domains.
- Certificate expiry check: reads the TLS certificate and warns days or weeks before it expires, leaving time to renew before browsers show errors.
- Heartbeat check: works in reverse. A scheduled job calls the monitor each time it runs, and you're alerted when a call doesn't arrive on time.
How often to check
The check interval sets how fast you can find out about an outage. With checks every 5 minutes, an outage can run for up to 5 minutes before the first failed check, plus the time to confirm it.
Shorter intervals detect problems sooner but send more requests and surface more brief network blips. A 1-minute interval suits pages where every minute of downtime costs money, and 5 minutes is enough for most others. Certificates and DNS change slowly, so hourly or daily checks cover them.
Set a request timeout well below the interval, and decide whether a slow response counts as degraded or down.
Confirm failures before alerting
One failed check is weak evidence. A dropped packet, a routing problem in one region or a fault at the monitoring provider can fail a check while your site works for everyone else.
The usual fix is to re-check from other locations and alert only when several locations agree, or after two or more consecutive failures. Each confirmation step adds a little detection time in exchange for fewer false alarms.
If one region keeps failing while the others pass, treat it as real. Users in that region may not be able to reach you.
Alert routing and status pages
Route alerts by urgency. A confirmed outage of a key page should reach the on-call person through a channel that wakes them, such as a phone notification or call. A warning like a certificate expiring in three weeks belongs in chat or email.
Each alert should say what failed, from which locations and since when, and link to a runbook. Send a recovery notice too, and tune or remove alerts that people routinely ignore.
A status page tells users what's happening without flooding support. Host it on separate infrastructure so it stays up when your site is down, and update it by hand during incidents, since automated checks miss partial outages.