Glossary
Clear, plain-language definitions of uptime monitoring terms: SLA, SLO, SLI, error budget, MTTR, heartbeat monitoring and more.
The practice of automatically checking whether a service is reachable and responding correctly, on a fixed interval, from one or more external locations. It answers a single question - is it up right now - and records the result so you can prove availability over time.
Any period in which a monitored service is unreachable or failing its checks. Downtime is measured from the first confirmed failed check to the first confirmed recovery, and is the inverse of uptime.
Availability expressed as a percentage of a period. "Three nines" (99.9%) allows about 43 minutes of downtime per month; "four nines" (99.99%) allows about 4 minutes. The more nines, the less downtime a service is permitted.
A contractual promise about a service, usually including a target availability (for example 99.9% per month) and the consequences if it is missed, such as service credits. An SLA is the external, customer-facing commitment.
The internal target a team holds itself to, usually set slightly stricter than any SLA. An SLO is a measurable goal - for example 99.95% successful checks over 30 days - that guides operational decisions before a customer promise is at risk.
The actual measurement an SLO is judged against - the ratio of good events to total events. For uptime that is typically the share of successful checks; for latency it might be the share of requests served under a threshold.
The amount of failure an SLO permits. A 99.9% monthly SLO leaves a 0.1% error budget - roughly 43 minutes. Teams spend the budget on risk (deploys, migrations) and slow down when it runs low, turning reliability into a number you can plan against.
The average time between a failure starting and the service recovering. Lower MTTR means outages are shorter. Fast detection and clear alerting are the levers that move it, which is why alert routing and incident workflows matter as much as the check itself.
Inverted monitoring for jobs that should run on a schedule. Instead of probing the job, you have it ping a URL on each run; if the expected ping does not arrive in time, the monitor fires. It is how you catch a cron job or worker that silently stops.
Confirming an outage from several geographic locations before alerting. A single failing probe can be a network blip on one route; requiring agreement across regions filters out false positives so alerts only fire on real, widespread failures.
A public page that shows the current and historical availability of your services, plus any active incidents or maintenance. It reduces support load during an outage by giving customers a single, trustworthy place to check.
A tracked record of a disruption - when it started, what was affected, the updates posted while it was open, and how it was resolved. Good incident handling turns a raw outage into a timeline you can communicate and learn from.
Actively probing a service with simulated requests on a schedule, rather than waiting for real user traffic to reveal a problem. Uptime, TCP, DNS, SSL and heartbeat checks are all forms of synthetic monitoring.
The time between sending a request and receiving the first byte of the response. It reflects server and network latency and is a common health signal in HTTP checks - a rising TTFB often precedes an outright failure.
Watching a TLS certificate for upcoming expiry and chain or configuration problems. Certificates expire on a fixed date, so a monitor that warns days in advance prevents the classic self-inflicted outage of a lapsed certificate.