What an availability target actually promises
An availability percentage is a downtime budget written as a fraction. When a provider commits to 99.9%, it is not promising that nothing will break; it is promising that unavailability will stay under one thousandth of the measurement window. Over a 30-day month that thousandth is 43.2 minutes. Over a year it is 525.6 minutes, or 8 hours 45 minutes.
The percentages compress badly at the top end, which is why engineers count nines instead. Each additional nine divides the allowed downtime by ten: 99% is two nines, 99.9% is three, 99.99% is four, 99.999% is five. Two nines gives you three and a half days a year to play with; five nines gives you five minutes. The interesting consequence is that at four nines and above, a single human-driven recovery is already too slow — if your monthly budget is 4.32 minutes, an engineer who needs ten minutes to read the page and log in has spent it before touching a keyboard.
Three numbers determine everything on this page: the target, the length of the window, and what you agree counts as downtime. The third is where most disputes start, and it is not a mathematical question at all.
The formula, and the two windows it can be measured over
The allowance is a straight multiplication. Convert the target to an unavailability fraction, then multiply by the number of minutes in the window:
allowed downtime = (1 − target/100) × window minutes
Reading it backwards is just as simple. Achieved availability is the fraction of the window during which the service worked: (window − downtime) ÷ window × 100. Converting that to nines uses a base-10 logarithm, because each nine is a factor of ten in the unavailability: N = −log₁₀(1 − A/100). An availability of 99.9% gives 1 − 0.999 = 0.001, and −log₁₀(0.001) = 3.00 nines exactly.
The window is the part worth arguing about. Two conventions are in common use. Calendar time counts every minute in the period, so a Sunday-night patch window counts against you exactly like an unplanned failure. Agreed service time removes contractually scheduled maintenance from the window before doing any arithmetic — the convention this calculator uses when you enter excluded minutes, and the one ITIL 4 describes for availability management. Removing four hours from a 30-day month leaves a 42,960-minute window, and a 99.9% target then allows 42.96 minutes rather than 43.2.
The difference is small in minutes and large in argument. Read the exclusions clause before you read the percentage: a 99.95% SLA that excludes eight hours of maintenance a month is a weaker promise than a 99.9% SLA measured against the calendar.
Worked example: 99.9% over a 30-day month with 26 minutes lost
Your contract promises 99.9% availability, measured monthly, with no excluded maintenance. In a 30-day month you recorded two incidents: a 19-minute database failover and a 7-minute load-balancer misconfiguration. Work it through:
- Window length. 30 days × 1,440 minutes = 43,200 minutes.
- Unavailability fraction. (100 − 99.9) ÷ 100 = 0.001.
- Allowed downtime. 43,200 × 0.001 = 43.2 minutes.
- Downtime recorded. 19 + 7 = 26 minutes.
- Achieved availability. (43,200 − 26) ÷ 43,200 = 0.9993981, so 99.93981%.
- Nines achieved. 1 − 0.9993981 = 0.0006019; −log₁₀(0.0006019) = 3.22 nines.
- Allowance remaining. 43.2 − 26 = 17.2 minutes for the rest of the month.
Now change one thing. Suppose the contract excludes a four-hour maintenance window each month. The window becomes 43,200 − 240 = 42,960 minutes, the allowance falls to 42.96 minutes, and achieved availability rises slightly to (42,960 − 26) ÷ 42,960 = 99.93947%. Shortening the window cuts the allowance and moves the measured percentage, so quoting an availability figure without naming its window is meaningless.
How to read the result: which number of nines you actually need
Pick the target from the consequences of being down, not from ambition. Three nines is the common commercial default for business software: 43 minutes a month is enough to absorb a failover, a bad deploy and a rollback. Four nines — 4.32 minutes a month — requires that recovery be automatic, because no on-call rotation responds that fast. Five nines is a claim about an entire architecture, including the network path and the change process, and buying it for one component of a chain buys you very little.
That last point deserves emphasis, because it is the most common way an availability target is quietly destroyed. Availabilities in series multiply. Chain five components that are each 99.9% available and the path is 0.9995 = 99.5%, which allows 216 minutes a month rather than 43.2. Work that arithmetic through with the system availability calculator before you promise a number to a customer.
Compare the achieved figure against the allowance rather than against the target percentage. A month at 99.87% sounds like a near miss on 99.9%, but in minutes it is 56 minutes against a 43.2-minute budget — a 30% overrun. Percentages at this end of the scale hide their magnitude; minutes do not. This is exactly why SRE teams track a error budget in minutes or bad requests rather than a rolling availability percentage.
Finally, remember what a breach is worth. Most SLAs pay service credits, typically a percentage of the monthly fee, and those credits are usually capped well below the cost of the outage to your business. If you want the real figure, put your revenue and headcount into the IT downtime cost calculator and compare it against the credit.
Allowed downtime by availability target
| Target | Nines | Per day | Per week | Per 30-day month | Per 365-day year |
|---|---|---|---|---|---|
| 99% | 2 | 14 m 24 s | 1 h 40 m 48 s | 7 h 12 m | 3 d 15 h 36 m |
| 99.5% | 2.30 | 7 m 12 s | 50 m 24 s | 3 h 36 m | 1 d 19 h 48 m |
| 99.9% | 3 | 1 m 26.4 s | 10 m 4.8 s | 43 m 12 s | 8 h 45 m 36 s |
| 99.95% | 3.30 | 43.2 s | 5 m 2.4 s | 21 m 36 s | 4 h 22 m 48 s |
| 99.99% | 4 | 8.64 s | 1 m 0.5 s | 4 m 19.2 s | 52 m 33.6 s |
| 99.999% | 5 | 0.86 s | 6.05 s | 25.92 s | 5 m 15.4 s |
Every cell is (1 − target) × the minutes in that period: 1,440 per day, 10,080 per week, 43,200 per 30-day month, 525,600 per 365-day year.
Partial outages are not partial minutes unless the contract says so
If one of twenty application servers fails and 5% of requests error for an hour, is that 60 minutes of downtime, 3 minutes, or none? All three answers appear in real contracts. Some SLAs define unavailability as a total loss of service; some use an error-rate threshold sustained over a defined interval; some prorate by the fraction of capacity affected. Cloud providers commonly define a monthly uptime percentage from the proportion of failed requests or of five-minute intervals with errors above a threshold, which is a different measurement from wall-clock outage time and produces different numbers from the same incident.
Fix the definition in writing before you fix the percentage, and make sure your monitoring measures the same thing the contract does. A calculator cannot settle a definitional argument.
Mistakes that make an uptime figure wrong
- Quoting a percentage without its window. 99.9% weekly is a far stronger promise than 99.9% annually — one bad hour breaches the week but is comfortable inside the year.
- Averaging monthly percentages to get an annual figure. Availability is a ratio of totals, so you must sum the downtime minutes and divide by the total window, not average twelve percentages.
- Assuming maintenance is excluded. Many SLAs count planned windows as downtime unless a specific exclusions clause says otherwise.
- Measuring from the wrong vantage point. A service that answers a health check inside the data centre can still be unreachable for customers. Measure from where the user is.
- Starting the clock at ticket creation. Outage duration runs from first customer impact to full restoration, not from when someone noticed.
- Promising a component target as an end-to-end target. Serial dependencies multiply, so a chain of 99.9% services is never 99.9% end to end.
- Confusing availability with reliability. A service that fails once for 40 minutes and one that fails forty times for a minute have identical availability and very different customer experiences.
What this calculator assumes, and what it leaves out
It treats downtime as whole minutes of total unavailability inside a single flat window, and it treats every minute as equally valuable. Real services are not like that: an hour lost at 03:00 on a Sunday costs less than four minutes lost during a Black Friday checkout peak. If your traffic is strongly diurnal, a request-weighted availability — good requests ÷ total requests — describes the customer experience far better than a time-weighted one, and it is what most modern SLOs use.
It also assumes you already know the downtime number. Deriving that from failure and repair statistics is a separate exercise: use the MTBF and MTTR calculator to turn a fleet's failure history into an expected availability, and the RPO and RTO calculator to size the recovery objectives that determine how long an incident lasts.
Nothing here models service credits, force-majeure clauses, the customer's obligation to report a breach within a claim window, or the effect of concurrent partial degradation. Those live in the contract, and they routinely matter more than the percentage on the front page.
Key terms
- Availability
- The fraction of the agreed service time during which a service performs its function, expressed as a percentage. It says nothing about how many separate failures produced that figure.
- Nines
- Shorthand for the number of leading nines in an availability figure, formally −log₁₀ of the unavailability. Each nine cuts allowed downtime by a factor of ten.
- SLA
- Service level agreement: the contractual commitment, usually with a remedy such as service credits attached to a breach.
- SLO
- Service level objective: the internal target a team runs against, normally set tighter than the SLA so there is room to react before a contractual breach.
- Agreed service time
- The window availability is measured over, after removing any contractually excluded maintenance. Also called scheduled service time.
- Service credit
- The remedy for a missed SLA, typically a percentage of the period's fee refunded on request. Almost always capped, and almost always smaller than the cost of the outage.