Answers · The systems around the model
Does a server being up mean my service is available?
In shortNo. A server being up only says a check got an answer; availability is the share of user requests that succeeded, measured where users are.
No. A server being up says that a machine or process answered a check, usually from inside the network. Availability is a ratio: the number of user events that succeeded divided by the total number of user events you decided to count, measured as close to the user as you can reach. Those are different questions, and the gap between them is where most outages hide: a host can answer every check it is asked while users cannot get an answer at all.
- the number of events that counted as successful
- the total number of events considered
The arithmetic that separates them
Take one minute with 10,000 user attempts. Suppose 200 fail at name lookup and 100 are dropped at the load balancer, so 9,700 reach the service. The service then answers 9,550 requests correctly in under two seconds, returns 50 correct refusals, and answers 100 correctly but after two seconds. The health check on the service returns 200 throughout, and the host stays up. It has answered every check it was asked. A dashboard built from that check will show a flat line at 100 per cent while 400 user attempts have already gone wrong.
| Outcome | Requests | Counts as success at the user | Seen by the service |
|---|---|---|---|
| Name lookup failed | 200 | no | no |
| Load balancer dropped | 100 | no | no |
| Correct refusal | 50 | yes | yes |
| Good response under two seconds | 9550 | yes | yes |
| Correct response after two seconds | 100 | no | yes |
| Total attempts | 10000 |
So the user sees 96.0 per cent availability while the service's own count, using the same rules but only on requests that reached it, gives 98.97 per cent. Even if the service had handled every request it received perfectly, the ceiling would be 9,700/10,000 = 97.0 per cent, because 300 attempts never arrived. The missing 3 per cent is not a service bug. It is a name lookup or load balancer failure, and it is invisible to a check that starts at the service. This is why the service's own opinion is useful for diagnosis and dangerous as the headline number.
What the uptime check misses
The natural guess is that if the host is up and the health endpoint returns 200, the service is available. That guess fails because it measures at the wrong point. A health check usually runs inside the network, after DNS and after the load balancer, against one instance. It can pass while users cannot resolve the name, while TLS is wrong at the edge, while the load balancer has no healthy targets, or while every response arrives after the user has left. None of those failures appear in the service's own counters, because the request never got there or the user stopped waiting. The check is diagnostic information, not the availability number.
The definition of success has to be fixed before the ratio means anything. A response after thirty seconds is a failure because the user is gone; the latency limit belongs inside success, and that limit is a product decision. A correct refusal is not a failure: the service did exactly its job. In the minute above, counting the 50 refusals as failures would change 9,600 successes into 9,550, so availability falls from 96.0 to 95.5 per cent, a half point lost by punishing correct behaviour. Counting the 100 slow responses as successes would change 9,600 into 9,700, raising availability from 96.0 to 97.0 per cent, a whole point gained by ignoring the user's wait. Same requests, different decisions, different number. A target without those decisions written down is not reproducible, and two honest teams can compute it differently.
Where it stops being enough
A host uptime check can be a reasonable proxy only in a narrow case: the only user is on the same machine, reaches the process without DNS or a load balancer, and has no latency requirement. Then the check and the user are in nearly the same place. For anything reached over a network, the measurement has to move as close to the user as you can reach. The window matters too. Four per cent unavailability over a thirty-day month is 0.04 times 43,200 minutes, which is 1,728 minutes, or 28.8 hours. Three nines over the same month is 43.2 minutes, and four nines is 4.32 minutes. The same incident can look tolerable over a year and catastrophic over a day, so a target without a window attached cannot be checked.
Those minutes are the form in which a target can be spent. If the only number you have is a host uptime gauge, you cannot tell whether you have 43 minutes or 1,728 minutes to spend, because the gauge never saw the failures that used them.
Worth keeping
- A host can be up while users cannot reach it, so host uptime is not availability.
- Availability is good user events divided by total user events, and both are definitions you choose.
- Three nines allows 43.2 minutes of downtime per month, so a target is better read as minutes than as a percentage.
Where this goes next
This question is one step of Running a Service That Stays Up, a course that works through its subject from the beginning. The page that teaches this part of it is A Number, Not a Feeling, and it reads the whole way through whether or not you have an account.
What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.
Read that pageThe whole courseOther questions people ask about this
- Why do retries make an overloaded service worse?Retries add extra requests precisely when a service is already too busy, so they turn a small overload into a much larger one and can keep the failure going by themselves.
- Why does latency explode when utilization gets close to 100%?Waiting time grows as one over the capacity you have left, so halving the spare capacity doubles the wait and the last few percent of load dominate.
- What's the difference between a CDN cache and caching inside my own app?A CDN cache sits near the user and can only hold answers that are identical for everyone, while a cache inside your app can be personal but exists once per process.
- What's the difference between LRU and LFU, and which one should I use?LRU drops the item unused for longest; LFU drops the item requested least often. Both guess at future use, and the cheap win is refusing one-off arrivals rather than counting requests.
- Why can't a system just stay consistent and available when the network splits?During a split, a cut-off machine can only answer from the data it already holds, so it must either risk being wrong or refuse to answer.
- How can I tell if my traffic is bursty or just high volume?Compare the variance of the gaps between arrivals with the square of their average gap: high volume alone does not make traffic bursty.