Availability targets are usually chosen the way round numbers always are: someone suggests one that sounds serious, nobody objects, and it goes in the contract.
Then it becomes an engineering constraint for years.
What the numbers actually permit
Over thirty days:
- 99.9% — 43 minutes of unavailability
- 99.95% — 21 minutes
- 99.98% — 8 minutes
- 99.99% — 4 minutes
Read that as a monthly budget you are allowed to spend. Eight minutes is one bad deploy caught quickly, or one restart of a stateful service that takes longer than expected. It is not enough for a human to be paged, wake up, understand the problem, and act. At 99.98%, recovery has to be automatic or the budget is already gone.
That is the real content of the number. It is not a quality statement — it is a statement about how much of your recovery path is allowed to involve a person.
The cost curve is not linear
Each additional nine roughly multiplies what you must invest: redundancy across failure domains, automated failover that is actually tested, deploy tooling that can roll back without human judgment, and an on-call rotation staffed well enough that response times are consistent at 3am.
Going from 99.9% to 99.99% is not “ten times better.” It is a different operating model.
Define the SLI before the SLO
The target is meaningless until you say what “up” means. Server-side liveness checks will happily report a healthy service while every user request fails at the edge. The measurement has to come from somewhere that resembles the user’s position — the load balancer at minimum, real user monitoring ideally.
We have seen a platform report 99.99% for a quarter in which customers experienced two multi-hour outages. Both numbers were accurate. Only one of them was about the customers.
Spend the budget deliberately
An error budget that is never spent means the target is too loose and you are over-investing in reliability at the expense of shipping. A budget that is always exhausted means the target is too tight for the system as designed.
The useful version has consequences attached and agreed in advance: when the budget is spent, feature work stops and reliability work starts, until it recovers. Without that, the budget is a dashboard nobody acts on.
Pick the number last
Work out what your users actually need, what your current architecture can sustain, and what the next nine would cost. Then choose. A target chosen this way is one you can defend in an incident review — and, more importantly, one you can meet.
