In minutes
A percentage is easier to argue about once it's turned into time. Over a year of 8,766 hours:
| Target | Down per year | Down per month |
|---|---|---|
| 99.5% | 1 day 19 h 49 min | 3 h 39 min |
| 99.9% | 8 h 46 min | 43 min |
| 99.95% | 4 h 23 min | 22 min |
| 99.99% | 53 min | 4 min |
Each extra nine divides the allowed downtime by ten. One good server with good backups can manage 99.5%. At 99.99% there isn't time for a person to wake up, log in and work out what's wrong, so the recovery has to happen by itself.
Dependencies multiply
A request usually goes through DNS, a load balancer, an application server, a database and maybe a payment provider. If each is up 99.9% of the time and any one of them can break the request, you multiply:
0.999 × 0.999 × 0.999 = 0.997 → 99.7%, about 26 hours a year
Every extra component in the chain brings the total down, even if each one is good. The useful question is which components sit in that chain and which can fail without users noticing.
Redundancy on paper
Put two independent components side by side, where either can handle the request, and they only fail together when both fail at once:
1 − (1 − 0.999)² = 0.999999 → 99.9999%
That's the case for clusters. It depends entirely on one word: independent.
Redundancy in real life
Redundant copies go down together far more often than that sum suggests:
- Same configuration. A bad setting pushed to both load balancers takes out both.
- Same software. A bug triggered by one odd request crashes every node that gets it.
- Same place. One rack, one power feed, one data centre, one cloud region.
- Same failover. A failover mechanism nobody has ever tried tends to fail the first time it's needed.
So real availability comes from rolling changes out to one node first, spreading out where it counts (two sites, sometimes two providers), and practising failover on a quiet day.
Planned work counts too
Your users can't tell an outage from a maintenance window. If the target is supposed to describe what users see, planned downtime counts. That means updates have to happen without stopping the service: restarting nodes one at a time, switching databases over, and changing database schemas in a way the running version can still cope with.
Up isn't the same as recoverable
Availability says how often the service is up. Two more numbers describe what happens when it isn't:
- Recovery time objective (RTO): how long getting it back may take.
- Recovery point objective (RPO): how much data you can afford to lose.
A system can be up all the time and still lose an hour of data if something corrupts it and the corruption copies straight to every replica. Backups with point-in-time recovery deal with that. Replication doesn't.
Picking a target
Start from what an hour of downtime costs you. A shop that loses real money every hour it's down can justify automatic failover. An internal tool used in office hours usually can't. Then measure from the outside, with checks that follow the path a real user takes, and compare the result with the target every month.
