Network Uptime and SLA Calculator
Calculate allowable downtime from SLA percentages. Convert 99.9%, 99.99%, and five-nines uptime to actual minutes per month and plan maintenance windows.
"We have 99.9% uptime" sounds impressive until you realize that's 8.7 hours of downtime per year. "Five nines" (99.999%) is only 5.26 minutes per year — and achieving that requires redundancy and failover that most organizations genuinely don't have. The CalcHub Network Uptime Calculator converts SLA percentages into real-time numbers so you can have honest conversations about reliability.
The Uptime Table That Changes Expectations
| SLA | Annual Downtime | Monthly Downtime | Weekly Downtime |
|---|---|---|---|
| 90% | 36.5 days | 72 hours | 16.8 hours |
| 95% | 18.25 days | 36 hours | 8.4 hours |
| 99% | 3.65 days | 7.2 hours | 1.68 hours |
| 99.5% | 43.8 hours | 3.6 hours | 50 min |
| 99.9% | 8.76 hours | 43.8 min | 10.1 min |
| 99.95% | 4.38 hours | 21.9 min | 5 min |
| 99.99% | 52.6 min | 4.38 min | 1 min |
| 99.999% | 5.26 min | 26.3 sec | 6 sec |
Composite Availability: Where Series Matters
If your service depends on multiple components that each have their own uptime SLA, the overall availability is the product of all of them:
Total Availability = A₁ × A₂ × A₃ × ...
Example: Your application depends on:
- Internet uplink: 99.9% uptime
- Load balancer: 99.99%
- Application servers (×2, parallel): 99.5% each
- Database: 99.95%
Two parallel application servers (both must fail for outage):
1 - (0.005 × 0.005) = 99.9975%
Total: 0.999 × 0.9999 × 0.999975 × 0.9995 = ~99.84% ≈ 12.7 hours downtime/year
The internet link is the weakest link and dominates the composite availability. The CalcHub calculator builds these dependency chains, shows the critical path, and identifies which component to upgrade first for the most reliability improvement.
Planned vs Unplanned Downtime
SLA calculations need to account for planned maintenance windows. If your SLA is "99.9% excluding planned maintenance" and you take a 2-hour maintenance window monthly, that's:
- Allowed unplanned downtime per month: 43.8 minutes
- Actual unplanned budget after planned maintenance: 43.8 minutes (planned is excluded)
Planning Maintenance Windows
The calculator can work in reverse: enter your SLA and any already-consumed downtime for the month, and it tells you how much time you have left for a maintenance window.
It also suggests maintenance windows by time zone — if you have global users, there's often no good time, but the calculator can find the minimum-impact window based on your user traffic distribution.
Tips
- Monitor with multiple probes. A single monitoring check from one location can be fooled by its own network issues. Use at least two monitoring providers from different data centers to confirm genuine outages.
- MTTR matters as much as MTBF. Mean Time to Recovery (how fast you fix it) is often more actionable than Mean Time Between Failures (how rarely it breaks). Faster incident response directly improves effective uptime.
- On-call doesn't solve 5-nines. Human response time for a 3 AM alert is measured in minutes. True 99.999% uptime requires automated failover that restores service in seconds without human intervention.
What does "five nines" actually require?
Five nines (99.999%) allows ~5.26 minutes of downtime per year. Achieving this requires: fully redundant infrastructure with no single points of failure, automated health checks with sub-30-second failover, redundant power (dual PSU + UPS + generator), redundant network paths (BGP multihoming or dual ISP), and zero-downtime deployment pipelines. It's genuinely expensive to operate.
How do AWS and Azure actually calculate their SLAs?
Cloud provider SLAs typically define "downtime" as inability to connect to the service for 5+ consecutive minutes. They measure it per region and per service tier. Multi-region deployments combine separate regional SLAs multiplicatively — if us-east-1 and eu-west-1 both have 99.99% SLAs and you're active-active across both, your effective availability is higher because both must fail simultaneously.
Should I target the same SLA for all components of my system?
No. Tier your reliability targets: user-facing APIs need the highest SLA; internal analytics pipelines can tolerate more downtime. Over-engineering background jobs to five-nines reliability wastes money that would be better spent on your critical path components.
Related Calculators
- Bandwidth Calculator — ensure bandwidth supports your uptime requirements
- Latency Calculator — performance alongside availability
- DNS Propagation Calculator — failover DNS planning