What an uptime percentage really promises
A service-level agreement (SLA) usually promises availability as a percentage of time: 99.9%, 99.95%, 99.99%. Those numbers look almost identical, but each extra nine cuts the allowed downtime by a factor of ten. This calculator converts the percentage into minutes and hours, which is what your users and your on-call team actually feel.
Allowed downtime = (1 − uptime ÷ 100) × length of the period
Real uptime = (1 − downtime ÷ length of the period) × 100
Downtime table for common targets
| Uptime | Per day | Per week | Per 30-day month | Per year (365 days) |
|---|---|---|---|---|
| 99% | 14.4 min | 1 h 40.8 min | 7 h 12 min | 3 days 15.6 h |
| 99.5% | 7.2 min | 50.4 min | 3 h 36 min | 1 day 19.8 h |
| 99.9% | 1.44 min | 10.1 min | 43.2 min | 8.76 h |
| 99.95% | 43.2 s | 5.04 min | 21.6 min | 4.38 h |
| 99.99% | 8.6 s | 1.01 min | 4.32 min | 52.6 min |
| 99.999% | 0.86 s | 6 s | 26 s | 5.26 min |
Worked examples
What does 99.9% allow per month?
A 30-day month has 30 × 24 × 60 = 43,200 minutes. The allowed share of downtime is 1 − 0.999 = 0.001. So 0.001 × 43,200 = 43.2 minutes. Over a 365-day year (525,600 minutes) the same target allows 525.6 minutes, or 8.76 hours.
Did we meet the SLA?
Your service was down for 90 minutes in a 30-day month. Real uptime = (1 − 90 ÷ 43,200) × 100 = 99.79%. That meets a 99.5% target (216 minutes allowed) but misses 99.9% (43.2 minutes allowed).
Why the month length matters
Providers define "a month" differently. Some use the calendar month, others an average of 730 hours. At 99.9%, a 730-hour month allows 43.8 minutes instead of 43.2. The difference is small, but it matters when you are close to the line, so the calculator lets you choose.
Chains and redundancy
A system is usually several components. If they are in series (each one must work), multiply their availabilities: two components at 99.9% give 0.999 × 0.999 = 99.80%, which is worse than either one. If they are redundant (any one is enough), the chance that all fail at once is what matters: two independent servers at 99% give 1 − 0.01 × 0.01 = 99.99%.
This is why a 99.99% promise usually requires redundancy at every layer: load balancers, application servers, database replicas and more than one data centre or availability zone. In practice failures are not always independent (a shared network or a bad deployment can take out both copies), so real-world availability is lower than the textbook figure.
Reading an SLA carefully
- Measurement window. Is uptime measured per month, per quarter or per year? A yearly target lets one bad month be balanced by good ones; a monthly target does not.
- Exclusions. Many SLAs exclude scheduled maintenance, problems caused by the customer and events outside the provider's control.
- What counts as "down". Some providers count only full outages, others count error rates above a threshold or slow responses.
- Remedy. Missing an SLA normally earns a service credit (a percentage of the monthly fee), not compensation for your lost business.
Choosing a realistic target
For an internal tool used during office hours, 99.5% may be perfectly fine. Customer-facing websites commonly aim for 99.9%. Payment systems and core infrastructure often aim for 99.95% to 99.99%, at a much higher cost in engineering and on-call staff. A target is only useful if you can measure it: set up external monitoring that checks the service every minute or so, and record incidents with start and end times.
Error budgets
Site reliability engineering turns an availability target into an error budget: the amount of failure you can afford. A 99.9% target allows 0.1% failures, which is 43.2 minutes of downtime in a 30-day month, or 1,000 failed requests out of every million. While budget remains, teams can ship changes faster; when it is used up, they slow down and focus on reliability.
How uptime is measured
- Synthetic checks: an external monitor requests a health URL every 30–60 seconds from several locations. Short outages between checks can be missed.
- Real user monitoring: counts successful versus failed real requests, which reflects what users actually experienced.
- Partial outages: decide in advance whether slow responses or one failing feature count as downtime.
The cost of each extra nine
Going from 99.9% to 99.99% reduces allowed downtime from 43.2 to 4.32 minutes a month. That usually requires automatic failover, redundant infrastructure across zones, careful deployment practices and round-the-clock on-call staff. Choose the target that matches what an outage really costs the business.
Frequently asked questions
How much downtime is 99.9% uptime?
About 43.2 minutes per 30-day month, 10.1 minutes per week, 1.44 minutes per day, or 8.76 hours per year.
How much downtime is 99.99% uptime?
About 4.32 minutes per 30-day month and 52.6 minutes per year.
What is the difference between 99.9% and 99.99%?
Ten times less downtime: 43.2 minutes versus 4.32 minutes per month. Reaching the extra nine usually needs redundancy at every layer of the system.
Does planned maintenance count as downtime?
It depends on the SLA. Many agreements exclude announced maintenance windows, but users still experience it as downtime, so plan maintenance for quiet hours.
How do I calculate uptime from an outage?
Divide the minutes of downtime by the minutes in the period, subtract from 1 and multiply by 100. 90 minutes in a 30-day month gives 99.79%.
What is an error budget?
The amount of unreliability an availability target allows. At 99.9%, it is 0.1% of time or requests, such as 43.2 minutes per 30-day month.
How often should uptime be checked?
External monitors commonly check every 30 to 60 seconds from several locations; real user monitoring adds a view of actual user experience.
Sources
- Published service-level agreements of major cloud providers (definitions of monthly uptime percentage, exclusions and service credits).
- Google, Site Reliability Engineering (O'Reilly, 2016), chapters on service level objectives and error budgets.
Last reviewed 5 October 2026. Results are estimates; see our disclaimer.