Uptime Calculator
Enter an uptime percentage to see exactly how much downtime it permits, or enter an outage you have already had to see which SLA level it still meets.
Uptime → allowed downtime
- Per year
- 8h 45m 36s
- Per month
- 43m 12s
- Per week
- 10m 5s
- Per day
- 1m 26s
Outage → achieved uptime
Achieved uptime
99.444%
That still meets a 99% commitment.
That outage breached a standard SLA level
A single slow recovery can consume an entire period's downtime budget, however well the rest of it ran. If that is a pattern rather than a one-off, the fix is usually architectural — and it is what we do.
What does an uptime percentage actually mean?
An uptime percentage is a promise about the proportion of a measurement window during which a service will be available. 99.9% uptime means the service may be unavailable for one tenth of one percent of the window — which sounds trivial until you convert it into wall-clock time and find it permits 43 minutes of outage every month.
The percentage on its own is close to meaningless without three further details: the length of the measurement window, what counts as an outage, and who measures it. A 99.9% commitment measured yearly tolerates a single eight-hour outage; the same 99.9% measured monthly does not. This is the detail most SLA disputes turn on, and it is almost always buried in a definitions section rather than stated next to the number.
How allowed downtime is calculated
The arithmetic is simple, and worth seeing rather than trusting — the allowed downtime is just the share of the window the commitment leaves unaccounted for.
-
Subtract the uptime percentage from 100 to get the permitted unavailability. For 99.9%, that is 0.1%.
-
Express that as a fraction: 0.1% becomes 0.001.
-
Multiply by the length of the measurement window in seconds. A 30-day month is 2,592,000 seconds, so 0.001 × 2,592,000 = 2,592 seconds.
-
Convert back into human units: 2,592 seconds is 43 minutes and 12 seconds.
This calculator uses a 365-day year and a 30-day month, which is the convention every major cloud provider uses in its own SLA. It matters more than it sounds: using a 365.25-day year would change the 99.999% figure by roughly eight seconds, and anyone comparing this page against an AWS or Azure SLA table would find a mismatch and trust neither.
Uptime and downtime reference table
The standard levels, converted. Most commercial SLAs sit somewhere between 99.5% and 99.99%; the five-nines row is included mainly because it is quoted far more often than it is contracted.
| Uptime | Per year | Per month | Per week | Per day |
|---|---|---|---|---|
| 90% | 36d 12h | 3d | 16h 48m | 2h 24m |
| 95% | 18d 6h | 1d 12h | 8h 24m | 1h 12m |
| 99% | 3d 15h 36m | 7h 12m | 1h 40m 48s | 14m 24s |
| 99.5% | 1d 19h 48m | 3h 36m | 50m 24s | 7m 12s |
| 99.9% | 8h 45m 36s | 43m 12s | 10m 5s | 1m 26s |
| 99.95% | 4h 22m 48s | 21m 36s | 5m 2s | 43s |
| 99.99% | 52m 34s | 4m 19s | 1m | 9s |
| 99.999% | 5m 15s | 26s | 6s | 1s |
Based on a 365-day year and a 30-day month, matching the convention used in published cloud provider SLAs.
Why each additional nine costs so much more
Every extra nine reduces the permitted downtime by a factor of ten, and the cost of achieving it does not scale down anything like as gracefully. The gap between 99% and 99.9% is mostly a matter of competent operations. The gap between 99.9% and 99.99% is usually an architectural change — redundancy across availability zones, automated failover, and the removal of every single point of failure you have been tolerating.
The last nine is the one to be careful about. Going from 99.99% to 99.999% leaves you roughly five minutes of downtime a year — less than a single unplanned reboot, and less than most deployment processes consume. Committing to it means every routine maintenance action has to be performed without interruption, which is a property of the architecture rather than something an operations team can promise through diligence.
What is a good uptime percentage to commit to?
The right level is the one where the cost of the next nine exceeds the cost of the downtime it prevents. For an internal reporting system used during business hours, 99% is often entirely reasonable and nobody notices the difference. For a payment path or a checkout flow, an hour of downtime can cost more than a year of the infrastructure needed to avoid it.
A practical approach is to work backwards from consequence rather than forwards from ambition. Estimate what an hour of unavailability actually costs — lost transactions, idle staff, support load, contractual penalties — and compare that against the engineering investment each additional nine requires. Committing publicly to a level you have not architected for is worse than committing to a lower one honestly, because the first outage turns an engineering problem into a contractual one.
How to improve uptime
Improving availability is mostly about removing single points of failure and shortening the time it takes to notice and recover from the failures that remain. In rough order of return on effort:
- Measure it honestly first. If you cannot say what your uptime was last quarter, any target is aspirational. Synthetic checks from outside your network are the minimum; they catch the outages your internal monitoring cannot see because it is inside the failure.
- Eliminate the single points of failure you already know about. Most teams can name them — the one database server, the manual failover step, the certificate somebody renews by hand.
- Shorten detection time. Time to recovery is usually dominated by time to notice, not time to fix, and alerting on symptoms users feel beats alerting on server metrics.
- Make routine maintenance non-disruptive. Once deployments, migrations and patching all require downtime, your planned maintenance is competing with your SLA for the same budget of minutes.
Redundancy is worth adding after those, not before. Redundant infrastructure that fails over slowly, or that has never been tested under a real failure, tends to convert short outages into long ones rather than preventing them.
Worked example: a 99.9% monthly SLA
Suppose you have committed to 99.9% availability measured monthly, and a database failover took four hours to complete on a Tuesday afternoon.
43m 12s
Per month
A 99.9% monthly commitment allows 43m 12s of downtime. A four-hour outage is roughly five and a half times that budget, putting the month at about 99.44% — which meets 99% but breaches 99.9%.
Note what this means for the rest of the window: a single four-hour outage exhausts the monthly budget entirely, so the SLA is breached regardless of how flawlessly the other 27 days ran. That asymmetry is why availability work concentrates on recovery time rather than failure frequency — one slow recovery costs more than several fast ones.
Common questions
What does an uptime percentage actually mean?
An uptime percentage is a promise about the proportion of a measurement window during which a service will be available. 99.9% uptime means the service may be unavailable for one tenth of one percent of the window — which sounds trivial until you convert it into wall-clock time and find it permits 43 minutes of outage every month.
How allowed downtime is calculated
The arithmetic is simple, and worth seeing rather than trusting — the allowed downtime is just the share of the window the commitment leaves unaccounted for.
What is a good uptime percentage to commit to?
The right level is the one where the cost of the next nine exceeds the cost of the downtime it prevents. For an internal reporting system used during business hours, 99% is often entirely reasonable and nobody notices the difference. For a payment path or a checkout flow, an hour of downtime can cost more than a year of the infrastructure needed to avoid it.
How to improve uptime
Improving availability is mostly about removing single points of failure and shortening the time it takes to notice and recover from the failures that remain. In rough order of return on effort:
Related reading
Cloud Cost Optimization Strategies: 10 Actionable Tactics
Explore 10 actionable cloud cost optimization strategies for mid-market and enterprise teams, covering rightsizing, autoscaling, FinOps, and observability.
What Is Infrastructure as Code: A Complete Guide for 2026
Learn what is infrastructure as code, how declarative and imperative approaches differ, and how to adopt IaC without losing control in 2026.
Business Continuity Best Practices: A 2026 Guide
Explore 10 business continuity best practices for software platforms. Learn to build resilient systems with tips on RTO/RPO, IaC, DR testing, and SRE.
Committed to a number you are not architected for?
Ryware designs and operates high-availability systems for organisations where downtime is measured in lost revenue rather than inconvenience — redundancy that has been tested under real failure, failover that completes without a person in the loop, and monitoring that notices before your customers do.