That last figure leaves about 5.26 minutes of downtime per year, and each extra nine cuts the allowance roughly tenfold. A conversion table follows, so you can translate any target into minutes.
TL;DR:
- Availability depends on the measurement window and whether planned maintenance or slow responses count, so define those rules before comparing service promises.
- Four nines suits payment and login systems; five nines suits emergency communications and core networks, requiring redundant regions and tested recovery.
- Service availability cannot exceed the combined reliability of required dependencies, so critical databases, networks, and identity providers need roughly one extra nine.
- A 99.9% SLO leaves a 0.1% error budget; teams can keep releasing while it remains, then prioritize reliability once it is exhausted.
- Choose a target based on downtime costs and the cost of higher reliability, then verify performance before promising a higher level.
Table of Contents
- What does each nine mean in minutes of downtime?
- How is availability calculated, and what counts as downtime?
- What do three, four, and five nines look like in practice?
- How do SLIs, SLOs, SLAs and error budgets fit together?
- Why do dependencies cap your availability, and how can you raise it?
- How do you choose an availability target and put it to work?
- What we have learned about keeping uptime promises
- Need help turning an uptime target into a working plan?
- FAQ
- Sources
What does each nine mean in minutes of downtime?
The table below assumes a 365-day year and shows the downtime each level allows. Figures are rounded, and the 99.99% row lines up with the roughly 53 minutes per year described in ACM Queue's availability analysis. The high availability overview carries the same standard "nines" table if you want a second reference.
| Nines | Uptime | Downtime per year | Per month (30 days) | Per week | Per day |
|---|---|---|---|---|---|
| 1 | 90% | 36.5 days | 3 days | 16.8 hours | 2.4 hours |
| 2 | 99% | 3.65 days | 7.2 hours | 1.68 hours | 14.4 minutes |
| 3 | 99.9% | 8.76 hours | 43.2 minutes | 10.1 minutes | 1.44 minutes |
| 4 | 99.99% | 52.6 minutes | 4.32 minutes | 1.01 minutes | 8.64 seconds |
| 5 | 99.999% | 5.26 minutes | 25.9 seconds | 6.05 seconds | 0.86 seconds |
| 6 | 99.9999% | 31.5 seconds | 2.59 seconds | 0.6 seconds | 0.09 seconds |
| 7 | 99.99999% | 3.15 seconds | 0.26 seconds | 0.06 seconds | 0.01 seconds |
| 8 | 99.999999% | 0.32 seconds | 0.03 seconds | 0.006 seconds | 0.001 seconds |
| 9 | 99.9999999% | 0.03 seconds | 0.003 seconds | 0.0006 seconds | 0.0001 seconds |
Contracts may display availability with varying precision, and a stated target is a commitment rather than a rounded figure. At very high availability targets, monitoring precision can become a concern.
How is availability calculated, and what counts as downtime?
The basic formula is simple: availability equals uptime divided by total time. To turn a percentage into downtime, multiply the total minutes in the period by (1 minus availability).
Two reliability terms drive the underlying math:
- MTTF (mean time to failure): the average time a service runs before it fails.
- MTTR (mean time to repair): the average time it takes to restore service after a failure.
- Availability = MTTF / (MTTF + MTTR): a service that runs 1,000 hours between failures and takes 1 hour to recover is about 99.9% available.
As ACM Queue explains, availability is really a function of how often outages happen and how long they last. That is why shortening recovery time can raise your nines as effectively as preventing failures. If you track incident timestamps, our piece on MTTR vs MTTA explains what to capture.
Measurement choices change the answer. A rolling measurement window and a calendar month can report different results for the same incidents. Planned maintenance may or may not count, so check the definition before you compare vendors.
Then there is the question of slow responses. A page that technically loads only after a long wait may feel down to the person waiting. Hyperping's availability guidance cautions that counting only hard errors can misstate availability, because responses slower than users will tolerate should be counted as failures. The same logic applies to latency in other systems: the team behind a camera database shows how to measure delay first before deciding what "too slow" means.
What do three, four, and five nines look like in practice?
Here are the common targets with exact allowances:
- 99% (two nines): 3.65 days per year, 7.2 hours per month, 1.68 hours per week, 14.4 minutes per day.
- 99.9% (three nines): 8.76 hours per year, 43.2 minutes per month, 10.1 minutes per week, 1.44 minutes per day.
- 99.99% (four nines): 52.6 minutes per year, 4.32 minutes per month, 1.01 minutes per week, 8.64 seconds per day.
- 99.999% (five nines): 5.26 minutes per year, 25.9 seconds per month, 6.05 seconds per week, 0.86 seconds per day.
Two nines suits internal tools where a slow afternoon is an annoyance, such as a reporting dashboard or a staging environment. Three nines is a common promise for customer-facing business applications, where a few hours of annual downtime is tolerable. Four nines fits payment flows, login systems and anything customers hit all day. Five nines belongs to emergency communications, core network backbones and global infrastructure, where a five-minute annual allowance is justified by the stakes.
Cost climbs steeply with each added nine. Going from three to four nines usually means automated failover, redundant everything and an on-call rotation that responds in minutes. Five nines typically demands multiple regions and tested recovery drills, because at 5.26 minutes a year a single human-handled incident can blow the entire budget.
Large providers often settle on a middle path. According to ACM Queue, operational practice at large cloud providers often targets 99.99% internally as a cost-effective balance.
Four nines allows about 53 minutes of downtime per year. One bad deployment or a slow failover can consume that entire allowance in a single afternoon.
How do SLIs, SLOs, SLAs and error budgets fit together?
These four terms describe a chain from measurement to promise to consequence:
- SLI (service level indicator): a measured value, such as the share of requests that succeed within a defined latency threshold.
- SLO (service level objective): the internal target for that indicator, such as 99.9% over 30 days.
- SLA (service level agreement): the external contract, usually looser than the SLO, with remedies such as credits if it is missed.
- Error budget: 1 minus the SLO. A 99.9% SLO leaves a 0.1% budget for failures.
The error budget turns an abstract percentage into a decision tool. Google's SRE error budget policy describes it as the allowed downtime that lets teams balance reliability against shipping updates: a team that has not exhausted its budget can keep releasing features, and a team that has should slow down and fix reliability first. Product and operations stop arguing about opinions and look at the same number.
Define your SLI carefully. If it counts only server errors, it will miss slow pages, timeouts and half-working features. Include latency thresholds that reflect what users actually experience. Also consider sampling: an infrequently checking probe can miss a brief outage entirely, and a low-traffic service may have too few requests in a measurement window to make a single percentage reliable. Probe frequently, from more than one location, and review results over a long enough window to be meaningful.
Pro Tip: *Set your SLA a notch below your SLO.
Why do dependencies cap your availability, and how can you raise it?
Availability compounds. If your service needs a database, a network and an identity provider to all be working, your uptime can never exceed the product of theirs.
That is the logic behind the rule of the extra nine. ACM Queue's analysis notes that critical dependencies typically need one more nine of availability than the service built on top of them. FireHydrant's practitioner guidance frames it as a roughly tenfold reliability gap, so a dependency's failures become negligible next to your own budget.
Patterns that raise effective availability:
- Replicate data and services so one failed node does not take the service down.
- Spread across zones or regions so a facility-level event is survivable.
- Send concurrent requests to redundant backends and use whichever answers first.
- Degrade gracefully by serving cached or reduced functionality when a non-critical dependency fails.
- Keep tested backups so recovery from data loss is a procedure, not an improvisation. Realistic timelines matter here, and this data recovery turnaround guide shows what recovery work actually takes.
Behind those patterns sit three levers. Reduce how often failures happen, reduce how many users each failure touches, and reduce how long recovery takes. For most teams, shrinking MTTR is the cheapest of the three.
How do you choose an availability target and put it to work?
Start with business impact, not ambition. Ask what an hour of downtime costs in lost sales, idle staff and damaged trust, then ask what each extra nine costs to build and run. Our downtime cost calculator turns that first question into a dollar figure, and our managed IT ROI breakdown shows how MTTR and uptime translate into numbers a CFO will accept.
Once you have a target, build the operating practice around it:
- Define SLIs that reflect user experience, including latency.
- Set alert thresholds based on error budget burn rate, not just raw failures.
- Write runbooks for the failures you expect, and rehearse them.
- Assign on-call ownership and an incident playbook with clear escalation.
- Review the SLO regularly and adjust it when the business changes.
- Keep backups and recovery plans current with backup and disaster recovery tied to a recovery time you have actually tested.
To check your arithmetic, our SLA uptime calculator converts any percentage into a downtime window.
Pro Tip: Choose the lowest target that the business can live with, then prove you can hit it for a quarter before you promise the next nine.
What we have learned about keeping uptime promises
In our experience, a guarantee is only as strong as the monitoring behind it and the recovery steps written down before anything breaks. A guarantee works when continuous monitoring catches trouble early, redundancy absorbs failures, and a runbook helps cut restoration time. We would rather you commit to a target your team can measure and defend than chase a bigger number that exists only in a contract.
— Alex
Need help turning an uptime target into a working plan?
We help small and mid-size businesses translate availability targets into monitoring, redundancy and faster recovery. Reach us through Managed IT Services and we will map your target to a plan you can measure.
- Proactive monitoring that flags problems before users notice.
- Redundancy and backup planning matched to your recovery goals.
- Clear incident response so recovery time keeps shrinking.
FAQ
What does 4 9s of availability mean?
Over a 365-day year, the allowance is about 52.6 minutes of downtime, which lines up with the roughly 53 minutes per year cited in ACM Queue's availability analysis.
How much downtime is 99.7 availability?
It allows about 26.3 hours of downtime per year, or roughly 2.16 hours per 30-day month. It sits between two nines and three nines, so it is not a standard "nines" tier, but the same formula applies.
What is six nines availability?
Few services are measured with such precision, because a single slow failover can use up the whole annual allowance.
What does it mean when a system has 99.999% availability?
It means the system can be unavailable for only about 5.26 minutes per year. Reaching that level generally requires redundant components across zones or regions, automated failover and tested recovery. As FireHydrant's guidance notes, critical components need to be roughly ten times more reliable than the system target.