99.9% uptime allows 8h 45m 36s of downtime per year — 43m 48s per month, 10m 5s per week, 1m 26s per day. Four nines (99.99%) cuts that to 52m 34s per year. Each extra nine divides allowed downtime by ten and multiplies the engineering cost of hitting it.
§1 · The nines table
Downtime = period length × (1 − uptime/100). Month is defined as year ÷ 12 (≈30.44 days) — the convention used by most SLA reference tables, so these numbers match what your vendor's lawyers mean.
| Uptime | Per day | Per week | Per month | Per year |
|---|---|---|---|---|
| 90% | 2h 24m | 16h 48m | 3d 1h | 36d 12h |
| 95% | 1h 12m | 8h 24m | 1d 12h 30m | 18d 6h |
| 99% | 14m 24s | 1h 40m 48s | 7h 18m | 3d 15h 36m |
| 99.5% | 7m 12s | 50m 24s | 3h 39m | 1d 19h 48m |
| 99.9% | 1m 26s | 10m 5s | 43m 48s | 8h 45m 36s |
| 99.95% | 43.2s | 5m 2s | 21m 54s | 4h 22m 48s |
| 99.99% | 8.6s | 1m 0.5s | 4m 23s | 52m 34s |
| 99.995% | 4.3s | 30.2s | 2m 11s | 26m 17s |
| 99.999% | 0.86s | 6.0s | 26.3s | 5m 15s |
| 99.9999% | 0.09s | 0.60s | 2.6s | 31.5s |
Reading it the other way: if you had a 22-minute outage this month, you are at 99.95% for the month — compute your own numbers (or your remaining budget) in the calculator.
Turn an outage into a percentage, or a target into a budget — plus composite SLAs in series/parallel.
Open uptime/SLA calculator →§2 · Error budgets: the useful way to read an SLA
SRE practice flips the table: a 99.95% monthly target is a budget of 21m 54s you get to spend. While budget remains, deploys and risky migrations are allowed; when an incident eats it, changes freeze until the window resets. Two consequences worth internalizing:
- A single bad deploy can spend a month. One 45-minute incident blows the entire 99.9% monthly budget — there is no partial credit for the other 29 flawless days.
- Budgets make "how reliable should we be?" a business question. If nobody notices 10 minutes of monthly downtime, paying engineers to chase four nines is buying insurance nobody asked for.
§3 · Composite SLAs: why your real number is lower
Availability in a dependency chain multiplies. Your API at 99.95% calling a database at 99.95% is 0.9995 × 0.9995 ≈ 99.90% — you lost half your promise by adding one hop. Five dependencies at 99.9% each: 0.999⁵ ≈ 99.50%, which the table above translates to almost 44 hours a year of allowed downtime from components that each sound excellent alone.
Redundancy runs the other way: two independent paths at 99% each, where either one suffices, give 1 − (0.01)² = 99.99%. That asymmetry — series destroys nines, parallel manufactures them — is the entire architecture argument in two formulas. The calculator's composite panel does both.
§4 · Choosing a target honestly
- 99.9% — the honest default for most SaaS: a maintenance window and the occasional bad deploy fit inside 43m/month.
- 99.95% — needs real redundancy and fast rollback; 21m/month disappears quickly.
- 99.99%+ — multi-region, automated failover, and an on-call rotation that actually wakes up. 4m 23s per month is less than one human reaction to a page.
- Whatever you promise, your dependencies cap it — compute the composite before signing the SLA, not after the first breach.
§5 · FAQ
How much downtime is 99.9% uptime?
1m 26s/day · 10m 5s/week · 43m 48s/month · 8h 45m 36s/year.
How much downtime is 99.99% uptime?
8.6s/day · ~1m/week · 4m 23s/month · 52m 34s/year. Each nine is a tenfold cut.
What is an error budget?
Your allowed downtime for the period, treated as spendable: deploy freely while it lasts, freeze when it's gone.
Why is my real availability lower than my components' SLAs?
Series dependencies multiply: five 99.9% services ≈ 99.5% composite. Parallel redundancy multiplies the failure probabilities instead — that's how you buy nines back.