A service can be 100% available, slow enough to be unusable, and unreliable in a way neither number shows. Three words, three measurements, and the gaps between them are where most disappointed users live.
Availability ¶
The proportion of checks that succeeded. The number on the badge.
Its weakness is entirely in the definition of "succeeded", and that definition is usually undocumented. Does a 200 with an error message count? A 403? A response that took 30 seconds? A check that failed because your monitoring was rate-limited?
This is not pedantry. On this site, one target read 100% uptime on its own page and appeared on the outage feed as down for 61 hours simultaneously, because two subsystems answered that question differently. The full post-mortem.
Three rules that make an availability figure mean something:
- Publish the denominator. 99.9% of what, measured how often, from where.
- Exclude checks that reached no conclusion. If a probe was rate-limited or blocked, it learned nothing — counting it as either success or failure invents data.
- Compute it from aggregate counts, not by averaging daily percentages. Averaging weights a sparse day the same as a busy one and can move a published figure by whole points.
Latency ¶
How long a response took. Almost always reported as an average, which is almost always the wrong statistic.
Averages hide the tail, and the tail is the experience. A service with a 200ms mean and a 4-second p99 is fast for most requests and unusable for one in a hundred — and if a user makes twenty requests to load a page, they hit that tail most of the time. Report p50, p95 and p99, or report nothing.
Latency also belongs inside availability rather than beside it. A response nobody waited for is not a success, so a slow threshold — record as degraded, do not fail — captures something a binary cannot.
Reliability ¶
Whether the service does the right thing, consistently, over time. It is the only one of the three that is about correctness, and the hardest to measure from outside.
A service can be available and fast and unreliable: it returns a result quickly, and the result is wrong, or it works for you and not for the person next to you, or it succeeds nine times and silently drops the tenth write. None of that appears in an uptime graph.
What actually measures reliability is the error rate of real user journeys, plus the shape of the failures. A one-in-a-thousand failure rate on a login flow is a reliability problem that will never register as an availability incident.
Where the three disagree ¶
| Situation | Availability | Latency | Reliability |
|---|---|---|---|
| Server pool half-unhealthy, retries hide it | 100% | up | bad |
| Database read replica serving stale data | 100% | fine | bad |
| Cold starts on every request | 100% | bad | fine |
| Maintenance page served with a 200 | 100% | fine | zero |
| Down for 3 seconds every hour | 99.9% | fine | bad |
That last row is the one worth sitting with. Three seconds an hour is 99.92% availability — inside most SLAs — and it will break every long-running connection, every upload, and every user unlucky enough to click at the wrong moment, seventy times a day.
What to report ¶
If you publish one number, publish availability with its definition attached, and never round it in the flattering direction. If you publish two, add p95 latency. If you publish three, add the error rate of the single journey that matters most — because that is the one your users would pick if you asked them.
And keep the impairment separate. "Available, with one request type failing" is a true and useful sentence that neither an uptime percentage nor a latency graph can express, and folding it into either one loses the only information that would have helped.
Turning the three into one decision ¶
The reason to separate these words is not taxonomy — it is that a team needs one number to decide whether to stop shipping features and go fix something. That is what an error budget is for, and it is more useful than it sounds once stripped of the jargon.
Pick a target that expresses the user's experience rather than the server's. "99.9% of checkout requests succeed in under 2 seconds" is one sentence containing all three words: availability (succeed), latency (under 2 seconds), and — because it names checkout rather than the homepage — reliability of the thing that matters.
The budget is what is left. At 99.9% over 30 days you have roughly 43 minutes of failure to spend. Spending it is fine; that is what it is for. Running out means the next work is reliability work, and the argument about whether things are "bad enough" has already been had, in advance, calmly.
The numbers that mislead most reliably ¶
- Uptime measured on the wrong endpoint. A CDN-cached homepage is close to 100% by construction. Reporting it as service availability is measuring your CDN provider.
- Mean latency. Hides the tail, which is the experience. Always p95 and p99 beside it.
- Availability over a long window. 99.9% monthly can be one 43-minute outage or 43 one-minute ones. The second is far worse for users and identical on the badge.
- Any figure without its denominator. Checked how often, from where, counting what as a success. Without those, the number is decoration.