What 99.9 percent really allows: uptime maths and how SLAs are measured
"Three nines" sounds like a quality. It is really a budget. 99.9 percent availability over a 30-day month allows 43.2 minutes of downtime, and not a second more. Whether that budget is generous or tight depends on three things the percentage does not tell you: the window it is measured over, what the contract leaves out, and where the measurement is taken.
This piece is mostly arithmetic. I have tried to show every step so you can check it, and so you can redo it with your own numbers in the uptime and SLA calculator.
The one formula
allowed downtime = (1 - availability) x window length
The window lengths used below:
| Window | Minutes |
|---|---|
| 365-day year | 525,600 |
| 30-day month | 43,200 |
| Week | 10,080 |
| Day | 1,440 |
So 99.9 percent of a 30-day month is 0.001 x 43,200 = 43.2 minutes, and 99.9 percent of a 365-day year is 0.001 x 525,600 = 525.6 minutes, which is 8.76 hours.
Downtime allowed at common targets
| Availability | Per year (365 days) | Per 30-day month | Per week | Per day |
|---|---|---|---|---|
| 99% | 87.6 h (3 d 15 h 36 min) | 7.2 h (7 h 12 min) | 1 h 40 min 48 s | 14 min 24 s |
| 99.5% | 43.8 h (1 d 19 h 48 min) | 3.6 h (3 h 36 min) | 50 min 24 s | 7 min 12 s |
| 99.9% | 8.76 h (8 h 45 min 36 s) | 43.2 min (43 min 12 s) | 10 min 4.8 s | 1 min 26.4 s |
| 99.95% | 4.38 h (4 h 22 min 48 s) | 21.6 min (21 min 36 s) | 5 min 2.4 s | 43.2 s |
| 99.99% | 52.56 min (52 min 33.6 s) | 4.32 min (4 min 19.2 s) | 1 min 0.48 s | 8.64 s |
| 99.999% | 5.256 min (5 min 15.36 s) | 25.92 s | 6.048 s | 0.864 s |
Two patterns are worth memorizing. Each extra nine divides the budget by ten. And 99.95 percent allows exactly half the downtime of 99.9 percent, a useful middle step when the next full nine is out of reach.
Real months are not 30 days. At 99.9 percent, a 28-day February allows 40.32 minutes and a 31-day month allows 44.64 minutes. Some calculators use the average month of 365.25 / 12 = 30.4375 days, which gives 43.83 minutes. A leap year allows 8.784 hours instead of 8.76. None of these differences is large, but when two parties compare reports and get different answers, this is usually the first reason.
The window changes the promise
Take one bad night: an 8-hour outage. Here is the same 99.9 percent target judged over different windows.
| Window | Budget at 99.9% | Availability with one 8 h outage | Target met? |
|---|---|---|---|
| Week | 10.08 min | 95.238% | No |
| 30-day month | 43.2 min | 98.889% | No |
| 90-day quarter | 129.6 min | 99.630% | No |
| 365-day year | 525.6 min | 99.909% | Yes |
The month calculation, for example, is 1 - 480 / 43,200 = 0.98889. Over a year the same outage fits inside the budget with about 45 minutes to spare. An annual window lets a provider have one terrible night and still report success. A monthly window catches it. When you read an SLA, find the window before you look at the number.
There is a second choice hiding here: calendar or rolling. A calendar month resets at midnight on the 1st, so an outage on the 31st is forgotten a day later. A rolling 30-day window keeps it on the books for a full 30 days. Contracts tend to use calendar months, since credits are applied to monthly bills. Internal targets work better on a rolling window, because the question you care about is "how much budget do we have left right now?" That is the error-budget idea described in the SRE material at sre.google, and it is also the right input for deciding which alerts deserve to page, as covered in alert fatigue.
Maintenance exclusions
Most SLAs exclude scheduled maintenance. The exclusion is reasonable, but it changes the arithmetic more than people expect.
Worked example: a 99.9 percent monthly SLA over a 30-day month, with up to 4 hours (240 minutes) of announced maintenance excluded.
measured window = 43,200 - 240 = 42,960 min
allowed unplanned = 0.001 x 42,960 = 42.96 min
total real outage = 240 + 42.96 = 282.96 min
calendar uptime = 1 - 282.96 / 43,200 = 0.99345 (99.345%)
Users can be without service for nearly 4 hours and 43 minutes in that month while the report says the 99.9 percent target was met. Measured against the calendar, the service delivered 99.345 percent, which sits closer to the 99.5 percent row of the table than to the 99.9 percent row.
Other clauses that move the numbers, and that are worth reading slowly:
- A minimum outage length. If outages under 5 minutes do not count, nine separate 4-minute drops (36 minutes of real downtime, 83 percent of a 43.2-minute budget) count as zero.
- Who measures. "As recorded by the provider's monitoring" means their probe, their location and their definition of down.
- Partial outages. Is high packet loss or a slow site "down", or only a total loss of service?
- Claim deadlines. Many contracts require you to request a credit within a set number of days, with evidence.
Serial and parallel: availability of a path
A user does not experience one device. They experience a path, and every part of it has to work. For components in series, multiply:
A(path) = A1 x A2 x ... x An
Worked example: a user at a branch office reaching an application at headquarters.
| Component | Availability | Unavailability |
|---|---|---|
| Branch internet circuit | 99.5% | 0.5% |
| Branch router | 99.95% | 0.05% |
| HQ internet circuit | 99.9% | 0.1% |
| HQ firewall | 99.95% | 0.05% |
| Application server | 99.9% | 0.1% |
| Whole path | 99.202% | 0.798% |
The product is 0.995 x 0.9995 x 0.999 x 0.9995 x 0.999 = 0.992018. Every component is at least 99.5 percent, yet the path delivers 99.2 percent. That is about 69.9 hours a year, or 344.8 minutes (5 h 45 min) in a 30-day month. A handy shortcut: when unavailabilities are small, you can add them. 0.5 + 0.05 + 0.1 + 0.05 + 0.1 = 0.8 percent, very close to the exact 0.798.
For redundant components, where any one of them is enough, multiply the unavailabilities and subtract from one:
A(parallel) = 1 - (1 - A1) x (1 - A2) x ... x (1 - An)
Add a second branch circuit from a different provider, also at 99.5 percent:
circuit pair = 1 - 0.005 x 0.005 = 1 - 0.000025 = 0.999975 (99.9975%)
whole path = 0.999975 x 0.9995 x 0.999 x 0.9995 x 0.999 = 0.996978 (99.698%)
The path improves from 99.202 to 99.698 percent: from about 69.9 hours of downtime a year to about 26.5 hours, or from 344.8 to about 130.5 minutes a month. The largest remaining contributors are now the HQ circuit and the application server at 0.1 percent each, so that is where the next improvement belongs.
The parallel formula assumes the two circuits fail independently and that failover is instant. Neither is guaranteed. Two circuits that share a conduit, a utility pole or an upstream carrier fail together. The router that switches between them is a serial component in its own right. And a failover that takes 3 minutes to notice the dead link spends 3 minutes of budget every time it happens.
Measuring from outside and from inside
Where you measure decides what you measure.
| Measured from | What it sees | What it misses |
|---|---|---|
| Inside (the NMS on the same LAN as the server) | Server, service and interface state, fine detail for diagnosis | The internet circuit, DNS, certificates, anything between the user and the building |
| Outside (a probe on another network) | What a user actually gets: DNS lookup, TCP connect, a real HTTP response | Why it failed |
An inside monitor will happily report an application as up while the HQ circuit is down and nobody outside can reach it. For SLA reporting, measure from outside, ideally from at least three locations, and only declare an outage when two of them agree, so a problem at one probe's own network does not count against you. Keep the inside monitoring for diagnosis.
Then check the resolution. A probe that checks every 60 seconds and needs 3 consecutive failures can never record an outage shorter than 2 minutes, may or may not catch one between 2 and 3 minutes, and starts its clock late. At 99.99 percent the monthly budget is 4.32 minutes. A monitor that checks every 5 minutes and counts each failed check as 5 minutes of downtime cannot measure that target at all, because a single failed check is already larger than the whole budget. The check interval should be a small fraction of the budget you are trying to measure. The trade-offs of shorter intervals are covered in choosing a polling interval.
Some targets count requests instead of minutes: 99.9 percent of requests succeed. With 2,000,000 requests in a 30-day month, 2,000 may fail. Traffic is not flat, though. At the average rate of about 46.3 requests a minute, a 10-minute outage fails about 463 requests. At a peak of three times the average, the same 10 minutes fails about 1,389, which is 69 percent of the month's budget. Request-based targets make an outage at 10 a.m. cost more than one at 3 a.m., which matches how users feel about it.
Before you sign, or promise
Run through this list for any SLA you buy and any target you offer:
- Which window: calendar month, rolling 30 days, quarter or year?
- What counts as down: total loss only, or errors, packet loss and latency too?
- Who measures, from where, and how often?
- How much maintenance is excluded, with how much notice?
- Is there a minimum outage length?
- What does the serial availability of your own path come to, and is the promised number even possible on top of it?
- How are credits claimed, and by when?
For the reporting side, the field manual page on administering a monitoring server shows how availability reports are built and how maintenance windows are kept out of them. Then put your own targets and windows into the calculator and see how many minutes you really have.
