Why measurement method matters
Two teams can both claim "99.9% uptime" and mean completely different things. Uptime is only meaningful once you know exactly what was measured, how often, and from where. Before trusting or reporting an uptime number, understand the measurement method behind it.
Synthetic monitoring
Synthetic monitoring sends artificial requests to your service at regular intervals — typically every 30 seconds to 5 minutes — from one or more external locations. If the request succeeds within an expected time and returns the expected response, the check passes.
Synthetic checks are simple and external, meaning they detect outages the way a real user would experience them. Their limitation is sampling: a 1-minute check interval can miss outages shorter than a minute, and an outage between two check intervals may go undetected entirely.
Heartbeat monitoring
Heartbeat monitoring works in reverse: the monitored service actively sends a signal ("I'm alive") to a monitoring system at regular intervals. If the heartbeat stops arriving, the system is presumed down. This is common for background jobs, cron tasks, and internal services that don't have a natural request/response pattern to check externally.
Health check endpoints
A health check endpoint is a dedicated URL (commonly /health or /healthz) that a service exposes specifically for monitoring purposes. A well-designed health check verifies not just that the process is running, but that its critical dependencies — database connections, downstream APIs, queue connectivity — are also functioning.
A shallow health check (just confirms the process responds) gives false confidence. A deep health check (verifies dependencies) gives a more accurate availability signal but can itself become a source of false positives if a non-critical dependency fails.
Request-based availability
The most accurate measure of user-experienced availability is the success rate of actual production requests — not synthetic checks. This is calculated as: (Successful requests ÷ Total requests) × 100, typically filtering for non-5xx HTTP responses.
Request-based availability captures real user impact directly, including partial degradations that synthetic checks at fixed intervals might miss. It requires no separate monitoring infrastructure beyond existing request logging or metrics.
Check frequency and detection latency
Check frequency directly limits how quickly an outage can be detected. A 5-minute check interval means outages can go undetected for up to 5 minutes before the first failed check — and typically 2-3 consecutive failures are required before alerting, to avoid false positives from transient network issues. This adds further detection latency.
| Check interval | Typical detection latency | Use case |
|---|---|---|
| 10–30s | 30s–2min | Critical production services |
| 1min | 2–5min | Standard production services |
| 5min | 10–15min | Internal tools, lower priority |
Detection latency directly affects MTTR — see What is MTTR? for how detection time fits into the overall recovery timeline.
Multi-region monitoring
Checking from a single location only verifies the service is reachable from that location. Multi-region synthetic monitoring (checking from several geographic points) distinguishes between a true outage and a regional network or DNS issue affecting only some users.
Most uptime monitoring services require 2 or more locations to agree before declaring an outage, reducing false alarms from transient regional connectivity issues.
How this connects to SLOs
Your choice of measurement method directly determines what availability number you can defend. If your SLO commits to request-based availability but you only have synthetic checks every 5 minutes, you cannot accurately verify SLO compliance. Align your measurement method with what your SLO actually promises before setting targets.
See What is an SLO? and the Availability Calculator to connect measurement to targets.