“Uptime”, “availability” and “reliability” get used interchangeably in marketing and mean different things in engineering. The differences matter the moment you sign an SLA, set an SLO, or argue about whether last night’s incident “counts”. Here’s the working vocabulary, with the math.
The three terms, precisely
Uptime — the proportion of time a system is running. It’s a machine-centric measure: the server is powered on and the process is alive. Uptime says nothing about whether anyone can use the thing.
Availability — the proportion of time the service is usable by its users. This is the user-centric measure, and the one worth caring about. A running server behind a broken load balancer, an expired certificate or a bad DNS record is up but not available — a distinction any external uptime monitor will reveal and an internal process check will hide.
Reliability — the probability the service performs correctly over an interval: not just reachable, but returning right answers at acceptable speed. A search API that responds in 30 seconds, or returns wrong results, is available but unreliable. Reliability is the broadest and hardest target; availability is one of its components.
Memorable version: uptime = is it on, availability = can I use it, reliability = does it work properly.
The downtime math behind the nines
| Target | Per day | Per month | Per year |
|---|---|---|---|
| 99% | 14.4 min | ~7.3 h | ~3.7 days |
| 99.9% | 1.44 min | ~43 min | ~8.8 h |
| 99.95% | 43 s | ~22 min | ~4.4 h |
| 99.99% | 8.6 s | ~4.4 min | ~53 min |
| 99.999% | 0.86 s | ~26 s | ~5.3 min |
Two practical truths hide in this table. First, each nine is a 10× cut in allowed downtime. Second, each nine costs disproportionately more — 99.99% typically demands redundant infrastructure, automated failover and 24/7 on-call; 99.999% is territory for payment networks and telecoms, not web apps. Promising more nines than you engineer for isn’t ambition, it’s a future refund program.
SLI, SLO, SLA — the measurement stack
These three acronyms turn the vocabulary above into something enforceable:
- SLI (Service Level Indicator) — the measurement. “Fraction of HTTP requests returning non-5xx within 500 ms.” An SLI is just a well-defined metric, fed by your monitoring.
- SLO (Service Level Objective) — the internal target for an SLI. “99.95% of requests succeed, measured over 30 days.” SLOs are engineering commitments, chosen deliberately.
- SLA (Service Level Agreement) — the external contract: the promise made to customers, with remedies (usually service credits) when broken. SLAs are written by lawyers and sales as much as engineers.
The sane relationship: SLA looser than SLO. If you promise customers 99.9%, target 99.95% internally — the gap is your margin for error. Running SLA = SLO means every internal miss is a contractual breach.
Error budgets: making the target useful
The most useful idea to come out of SRE practice: invert the SLO. A 99.9% availability objective means 0.1% unavailability is allowed — ~43 minutes per month. That’s a budget, and you spend it:
- Budget remaining → ship features, run risky migrations, deploy on Friday if you dare.
- Budget exhausted → freeze risk, prioritize reliability work until the window rolls over.
This converts the eternal “move fast vs stay stable” argument into arithmetic both sides can read off a dashboard. It also reframes incidents: a 10-minute outage isn’t a moral failing, it’s 23% of the monthly budget — information, not blame.
What this means for your monitoring
- Measure availability from outside. Users experience your DNS, CDN, certificates and network — not your process table. External checks are the only honest SLI source for availability (how to set them up).
- Measure reliability, not just reachability. Add response-time thresholds and content checks; “slow is the new down” and correctness failures never show in a ping. Synthetic monitoring extends this to full user journeys.
- Check the SLA’s fine print. How is downtime measured, over what window, with what exclusions? An SLA measured by the vendor’s own internal monitoring, monthly, excluding “scheduled maintenance”, promises much less than its headline number.
- Keep the receipts. Your own monitoring history is your evidence for SLA claims against providers — and your dataset for setting realistic SLOs. Any serious uptime monitoring tool retains this history for you.