Five nines: carrier-grade territory
Five nines is a total budget of 5 minutes 15 seconds per year, less than a single router reboot. One DNS hiccup or a TLS renewal gone wrong spends the lot, which is why almost no web-facing service genuinely commits to it.
The standard comes from telephone switching, where interconnect contracts demanded it and the hardware was purpose-built for redundancy: fully redundant paths, automatic failover, no human in the loop. Users never observe the failure that consumed the budget; only the metrics record it.
What committing to five nines actually costs
Every mitigation has to be pre-programmed, because the annual budget is shorter than the time it takes to conference in an engineer: N+2 redundancy, isolated failure domains, and the capacity to lose an entire region without user impact.
The honest question is economic. Each nine costs roughly ten times the last, and the final step to five often exceeds the value of the downtime it prevents. Most services claiming 5 9s exclude maintenance windows or measure a single layer rather than the whole path, so ask for historical, independently verifiable data before accepting one in a contract. Many teams do better committing to 99.99% and consistently beating it.
Failure masking is the five-nines operating model
At five nines, repairing a visible outage is already too late. The service has to stay usable by moving traffic, serving safe cached data, or disabling nonessential features while the failed component recovers outside the request path.
Every fallback needs regular production-like testing. An untested replica, stale routing rule, or dormant recovery region is only theoretical redundancy, and discovering that during an incident spends the full budget at once.
The dependency math behind five nines
Five required components at 99.999% each combine to roughly 99.995% before correlated failures are considered. Shared networks, control planes, and deployment tooling make the real result worse because those failures are not independent.
A credible design removes dependencies from the critical path, provides alternate providers, or keeps a safe local fallback. Simply buying five separate five-nines SLAs does not create a five-nines service.
Where five nines can make economic sense
The investment can make sense for telephone switching, payment settlement, emergency dispatch, and other systems where seconds of unavailability create outsized financial or safety consequences. The business impact has to justify continuous redundancy and testing.
Define the protected transaction narrowly. Keeping payment authorization available may be essential while receipts, reporting, and account settings can degrade safely. That separation prevents an expensive target from spreading to features that do not need it.
What 26 seconds per month changes
A conventional rolling deploy, database promotion, or DNS change can last longer than the monthly allowance. Releases need canaries, connection draining, backward-compatible data changes, and automatic rollback before broad exposure.
Capacity tests must also cover a full failure domain disappearing. Redundancy is only useful when the surviving instances can absorb the traffic immediately without latency or error rates crossing the availability threshold.
How to audit a five-nines claim
Ask whether the figure covers the complete user transaction or one component, whether planned maintenance is excluded, and whether degraded responses count as available. Small changes to those definitions can turn ordinary performance into a five-nines report.
Request several years of raw measurements because a short incident history proves little at this scale. Evidence from independent locations and documented failover tests is more persuasive than an SLA credit that activates only after the target has already failed.
Downtime allowed at each SLA level
| Uptime | Per day | Per month | Per year |
|---|---|---|---|
| 99% Two nines | 14m 24s | 7h 12m | 3d 15h |
| 99.9% Three nines | 1m 26s | 43m 12s | 8h 45m 36s |
| 99.95% | 43s | 21m 36s | 4h 22m 48s |
| 99.99% Four nines | 9s | 4m 19s | 52m 34s |
| 99.999% Five nines | 864ms | 26s | 5m 15s |
| 99.9999% Six nines | 86ms | 3s | 32s |
| 99.9999999% Nine nines | 86μs | 2.6ms | 32ms |
SLA calculation cheatsheet
Availability calculation
Availability (%) = (Total Time - Downtime) / Total Time × 100Example: If a service was down for 7.3 hours in a 30-day month:
- Total Time = 30 days × 24 hours = 720 hours
- Availability = (720 - 7.3) / 720 × 100 = 98.99%
Response time SLA
Response Time Compliance (%) = (Responses Within Threshold / Total Responses) × 100Mean time metrics
- MTBF (Mean Time Between Failures) = Total Operational Time / Number of Failures
- MTTR (Mean Time To Repair) = Total Repair Time / Number of Repairs
- MTTA (Mean Time To Acknowledge) = Total Time to Acknowledge / Number of Incidents
Service credit calculation
Service Credit = (Monthly Service Fee) × (Credit Percentage for SLA Breach)SLA penalty example
- If availability drops below 99.9% but remains above 99.0%: 10% credit
- If availability drops below 99.0%: 25% credit
Track SLAs and downtime metrics at a glance
Hyperping reports on service reliability using data collected by your monitors. Select the reporting period, then review the results in the dashboard or export them.
- Track uptime, Mean Time to Recovery (MTTR), and SLA compliance for any reporting period.
- Export the selected period as a CSV file for audits, client reports, spreadsheets, or internal analysis.
- Review the complete incident history and use filters to narrow the records included in your report.
SLA & uptime management guides
What is uptime?
Uptime is the amount of time that a service is available and operational, typically expressed as a percentage over a given period such as a month or a year.
What is an SLA?
A service-level agreement (SLA) defines the level of service you expect from a vendor, laying out the metrics by which service is measured, as well as remedies or penalties should agreed-on service levels not be achieved.
How to prevent downtime?
Redundancy, monitoring and alerting are key to ensure a safe and reliable service.
Frequently asked questions
- How do you calculate availability?
- Availability (%) = (Total Time − Downtime) / Total Time × 100. For example, a service that was down 7.3 hours in a 30-day month (720 hours) has an availability of (720 − 7.3) / 720 × 100 = 98.99%.
- How much downtime does 99.999% uptime allow?
- At 99.999% uptime, the maximum allowed downtime is 864ms per day, 26 seconds per 30-day month, and 5 minutes 15 seconds per 365-day year.
- What's the difference between 99.9% and 99.99% uptime?
- Each additional nine reduces allowed downtime tenfold: 99.9% allows about 8 hours 46 minutes of downtime per year, while 99.99% allows just under 53 minutes. Meeting 99.99% generally requires automated failover, since a human response rarely fits inside the budget.
- How do I track SLA compliance?
- Continuous uptime monitoring measures availability from outside your infrastructure and records every outage. Hyperping checks your endpoints at up to 30-second intervals from multiple regions and reports uptime, MTTR, and SLA compliance over any period.
- How difficult is five nines uptime?
- Five nines is difficult because it permits only about 5 minutes 15 seconds of downtime per year. Achieving it generally needs fault-tolerant architecture, automated recovery, controlled changes, and dependencies with compatible availability targets.