Tools Updated
Uptime and availability table: downtime per “nines”
The maximum total downtime each availability (uptime) target allows. 99.9% (“three nines”) allows 43m 12s in a 30-day window and 8h 45m 58s per year.
On this page
| Availability | Day | Week | 30 days | Month (avg.) | Quarter | Year |
|---|---|---|---|---|---|---|
| 90%One nine | 2h 24m | 16h 48m | 3d | 3d 1h 3m | 9d 3h 9m | 36d 12h 36m |
| 95% | 1h 12m | 8h 24m | 1d 12h | 1d 12h 32m | 4d 13h 35m | 18d 6h 18m |
| 97% | 43m 12s | 5h 2m 24s | 21h 36m | 21h 54m 54s | 2d 17h 45m | 10d 22h 59m |
| 98% | 28m 48s | 3h 21m 36s | 14h 24m | 14h 36m 36s | 1d 19h 50m | 7d 7h 19m |
| 99%Two nines | 14m 24s | 1h 40m 48s | 7h 12m | 7h 18m 18s | 21h 54m 54s | 3d 15h 40m |
| 99.5%Two and a half nines | 7m 12s | 50m 24s | 3h 36m | 3h 39m 9s | 10h 57m 27s | 1d 19h 50m |
| 99.8% | 2m 53s | 20m 10s | 1h 26m 24s | 1h 27m 40s | 4h 22m 59s | 17h 31m 55s |
| 99.9%Three nines | 1m 26s | 10m 5s | 43m 12s | 43m 50s | 2h 11m 29s | 8h 45m 58s |
| 99.95%Three and a half nines | 43.2s | 5m 2s | 21m 36s | 21m 55s | 1h 5m 45s | 4h 22m 59s |
| 99.99%Four nines | 8.64s | 1m | 4m 19s | 4m 23s | 13m 9s | 52m 36s |
| 99.995% | 4.32s | 30.2s | 2m 10s | 2m 11s | 6m 34s | 26m 18s |
| 99.999%Five nines | 864ms | 6.05s | 25.9s | 26.3s | 1m 19s | 5m 16s |
| 99.9999%Six nines | 86.4ms | 605ms | 2.59s | 2.63s | 7.89s | 31.6s |
How the numbers are calculated
allowed downtime = (1 − availability) × period length
For 99.9% over 30 days: 0.001 × 30 × 86,400 s = 2,592 s = 43 minutes 12 seconds. Published tables disagree by a few seconds or minutes because they define “month” and “year” differently. This page uses a 365.25-day year (which averages leap years), a month of one twelfth of that year (30.44 days), and a quarter of one quarter of that year. The 30-day column suits a rolling 30-day SLO. The SRE Workbook recommends 28 days (four whole weeks) so every window holds the same mix of weekdays and weekends; contracts usually mean a calendar month. Use whichever definition your SLO or SLA states.
Every additional nine divides the allowance by ten. Going from 99.9% to 99.99% cuts a year’s downtime from almost nine hours to under an hour, and the engineering cost of each nine usually rises much faster than linearly.
What “downtime” means in practice
The table assumes a binary, time-based definition: the service is either fully up or fully down. Real systems rarely fail that cleanly, so be explicit about which definition you use:
- Time-based availability counts minutes in which the service is “good”, often defined as an SLI above a threshold in each minute. A 5% error rate for an hour can count as an hour of downtime or as none, depending on the threshold.
- Request-based availability is good requests ÷ valid requests. With steady traffic, one hour at 5% errors spends the same budget as three minutes at 100%; at uneven traffic, failures at peak spend more. Most modern SLOs use this form because it weights by real user impact.
- Planned maintenance is downtime to users. Contracts often exclude it from an SLA, but an internal SLO that excludes it hides real unavailability.
Converting a request-based budget to “minutes of full outage” is still useful for intuition, assuming steady traffic: a 99.9% request SLO over 30 days can absorb roughly 43 minutes of total failure, or about 7 hours 12 minutes at a 10% error rate. The error budget calculator does this for any target and error rate.
Composite availability: dependencies and redundancy
If a request needs several components, and they fail independently, multiply their availabilities:
serial: A = A₁ × A₂ × … × Aₙ
A service that needs a load balancer at 99.95%, an application tier at 99.9% and a database at 99.99% can be at most 99.840% available — lower than any single part. Hard dependencies set a ceiling on your own target.
If any one of several redundant replicas is enough, the system fails only when all of them fail at once:
parallel: A = 1 − (1 − A₁) × (1 − A₂) × … × (1 − Aₙ)
Two independent 99.5% replicas give 99.9975% in theory.
The independence assumption is usually optimistic. Replicas share deployments, configuration, regions, DNS, certificates and people. Failover is not instantaneous and fails sometimes. Correlated failures make the real figure lower than the independent-failure estimate, so treat it as an often optimistic estimate and measure the real thing with an SLI.
Choosing a target
- Start from what users need and what you can measure today, not from the highest number marketing likes.
- Your target cannot exceed the composite availability of your hard dependencies unless you add redundancy or graceful degradation.
- Above a certain point users cannot tell the difference: their networks and devices fail more often than your service. Extra nines then cost engineering time without visible benefit.
- Leave headroom between an internal SLO and any external SLA, so you react before contractual penalties apply.
Sources: Google, Site Reliability Engineering, ch. 3 “Embracing Risk”; ch. 4 “Service Level Objectives”.