Uptime / Downtime Calculator
Convert any uptime % (like 99.9%) into allowed downtime per day, week, month or year — with a full nines table.
Formula last reviewed 4 August 2026 · How we verify our calculators
Allowed downtime / month
43m
- In minutes
- 43
- In hours
- 1
- Downtime per year
- 8h 46m
Updates live as you type
Frequently asked questions
Downtime = period × (100 − uptime%). Over a 30-day month, 99.9% allows about 43.2 minutes; over a year, about 8.76 hours.
Multiply the total time in the period by the failure fraction (100 − uptime%) ÷ 100. The tool does this for any uptime value, including ones not on the standard nines table like 99.95% or 99.97%.
Each nine is an availability tier: 99% (two nines), 99.9% (three), 99.99% (four), 99.999% (five). Adding a nine reduces allowed downtime roughly tenfold.
An SLA often states an uptime percentage, so this tells you the downtime that percentage permits. But the SLA is the contract; your internal SLO is usually set tighter so you breach it first as a warning.
It depends on the agreement. Many SLAs exclude announced maintenance windows from downtime, so read the specific terms before assuming this figure is the whole story.
Converting a percentage into an actual outage
An uptime of 99.9% allows 43 minutes of downtime a month — 43.2 minutes precisely, or 0.72 hours. Across a full year that is 8 hours 46 minutes.
The percentage form is convenient and almost useless for planning. The duration form is what tells you whether your on-call rotation, your deployment process and your maintenance approach are compatible with the number you have committed to.
The calculation
Allowed downtime = period duration × (1 − uptime ÷ 100)
For a month, taken as 30 days: 30 × 24 × 60 = 43,200 minutes. Multiply by 0.001 (the 0.1% shortfall from 99.9%) to get 43.2 minutes.
The same arithmetic over any period:
- 99% — 14m 24s a day, 7h 18m a month, 3d 15h a year
- 99.9% — 1m 26s a day, 43m a month, 8h 46m a year
- 99.95% — 43s a day, 21m 54s a month, 4h 23m a year
- 99.99% — 8.6s a day, 4m 23s a month, 52m 36s a year
- 99.999% — 0.86s a day, 26s a month, 5m 15s a year
Read down the "per year" column and the engineering implication becomes concrete. At three nines you can absorb a single bad afternoon. At four nines, one 52-minute incident consumes the entire annual allowance. At five nines, a service cannot be restarted manually — five minutes is less than the time it takes a human to be paged, wake up and log in, which is why five nines implies fully automated failover as a design requirement rather than an aspiration.
Availability in series and parallel
Composing systems changes the arithmetic in ways that are easy to get backwards.
In series — where every component must work — availabilities multiply. Three components at 99.9% give 0.999³ = 99.7%, roughly 26 hours a year. Adding dependencies always lowers availability, which is the quantitative argument against unnecessary services in a critical path.
In parallel — where any one component suffices — the failure probabilities multiply instead. Two independent components at 99% each give 1 − (0.01 × 0.01) = 99.99%. This is why redundancy is powerful, and why the word *independent* is doing all the work: two servers in the same rack on the same power feed are not independent, and the arithmetic quietly stops applying.
Scheduled maintenance
Whether planned downtime counts is a decision, not a fact. Most commercial SLAs exclude announced maintenance windows. Most internal SLOs include them, on the reasoning that users experiencing an outage do not care whether it was on a calendar.
The stricter internal treatment tends to be the more useful one, because it creates pressure towards zero-downtime deployment techniques — rolling updates, blue-green, canary releases — rather than towards scheduling more maintenance windows.
Common mistakes
Using 30 days as a month everywhere. Months vary from 28 to 31 days; a 31-day month allows about 44.6 minutes at 99.9% rather than 43.2.
Promising availability above your dependencies. A service on 99.9% infrastructure cannot honestly offer 99.99%.
Assuming redundancy is independent. Shared power, shared network, shared configuration and shared deployment pipelines are all correlated failure modes.
Forgetting that the clock includes nights and weekends. Annual allowances are consumed by incidents at 3 a.m. exactly as by incidents at midday.
Treating uptime as the only measure. A service that is up but returning errors or taking thirty seconds to respond is up by this definition and down by any user's.