The nines of availability
Availability targets are written as percentages, and the industry shorthand counts the nines in them: 99% is "two nines", 99.9% is "three nines", and so on. Each added nine divides the allowed downtime by ten — and multiplies the cost of achieving it by roughly as much.
The table that matters
Percentages hide the meaning; minutes reveal it. For a 30-day month:
| Availability | Downtime allowed per month | Downtime allowed per year |
|---|---|---|
| 90% (one nine) | 72 hours | ~36.5 days |
| 99% (two nines) | ~7.2 hours | ~3.7 days |
| 99.9% (three nines) | ~43 minutes | ~8.8 hours |
| 99.99% (four nines) | ~4.3 minutes | ~53 minutes |
| 99.999% (five nines) | ~26 seconds | ~5.3 minutes |
Read the three-nines row twice: 99.9% sounds modest next to competitors advertising more, yet it allows only 43 minutes a month. One mishandled deployment can spend the whole budget — what is downtime lists where those minutes usually go.
What each nine costs in practice
- 99% — a single, competently managed server reaches this. Seven hours of monthly slack absorbs a reboot, a failed disk swap, an unhurried fix.
- 99.9% — needs monitoring that alerts within minutes, disciplined change management, and someone who actually responds. Achievable on well-run SME infrastructure without exotic architecture — but there's no room left for "we'll look at it after lunch."
- 99.99% — the human becomes the bottleneck. With a 4.3-minute monthly budget, an engineer who reads the alert email and fixes the fault in twenty minutes has just spent almost five months of allowance. Four nines requires automatic failover, redundancy everywhere, and an on-call rotation.
- 99.999% — the territory of multi-region organizations; 26 seconds a month leaves no role for humans in recovery at all. Note the measurement floor, too: with one-minute checks, a single failed check registers roughly a minute of downtime — more than double the entire five-nines monthly budget. Nobody can verify five nines with minute-level checks, and nobody should promise it on infrastructure measured that way.
Which nine does a typical MSP client need?
Honestly: usually fewer than they first ask for. For a company website, mail, or an internal ERP, a monthly target of 99.5%–99.9% is meaningful, achievable, and defensible. Promising 99.99% for a workload running on a single server isn't ambition — it's a written commitment to fail, because the architecture can't deliver what the contract says.
The sound approach is to pick the number the architecture and budget actually support, write it into the SLA, and measure it continuously. Many teams also keep a stricter internal objective as a buffer above the contractual number — that's the SLA / SLO / SLI split. In UpAll, each client can carry an SLA target, and the monthly SLA report shows measured uptime against it, with downtime minutes and the incident log to back the number.