"99.9% uptime" sounds like a small, almost meaningless gap from perfect. In practice it's the difference between an outage nobody notices and one that ends up in a postmortem. Whether you're reading a vendor's SLA, writing an incident report, or trying to work out what your app's real availability is once you account for the database, the CDN, and the auth provider it depends on, the maths behind "the nines" is simple once you see it laid out — and easy to get subtly wrong (most people average SLAs together when they should be multiplying them). This is a walkthrough of both.
- 99.9% uptime ("three nines") allows about 8 hours 45 minutes 36 seconds of downtime a year on the standard 365-day convention
- Each extra nine cuts permitted downtime by roughly a factor of ten
- For services that depend on each other, multiply availabilities together — never average them
- Two services each at 99.9% combine to about 99.8%, not 99.9% — a real, common mistake
- The year/month length convention you use (365 vs 365.25 days, fixed vs calendar-average month) changes every downtime figure, so check it before comparing two SLA calculators
What Does 99.9% Uptime Actually Mean?
"99.9% uptime" is a percentage of time, not a vague quality score. To turn it into something concrete, take the length of the reporting period and multiply it by the 0.1% that's allowed to be down. On the 365-day year / calendar-average month convention (30.44 days — the convention this calculator defaults to, since it's the one most billing and monitoring periods actually use):
| Period | Downtime allowed at 99.9% |
|---|---|
| Daily | 1 minute 26 seconds |
| Weekly | 10 minutes 5 seconds |
| Monthly | 43 minutes 50 seconds |
| Quarterly | 2 hours 11 minutes 24 seconds |
| Yearly | 8 hours 45 minutes 36 seconds |
These numbers move if the convention moves. A 365.25-day year (accounting for leap years) or a fixed 30-day month instead of the 30.44-day calendar average both produce slightly different figures — which is exactly why two SLA calculators can disagree on "the same" percentage without either being wrong. Check which convention a vendor's number assumes before you compare it to your own monitoring dashboard.
The Nines, From One to Six
Each additional "nine" in an uptime percentage cuts the permitted downtime by roughly a factor of ten. Here's the full reference table, again on the 365-day convention:
| SLA | Common name | Downtime per year |
|---|---|---|
| 90% | one nine | about 36 days 12 hours |
| 95% | one and a half nines | about 18 days 6 hours |
| 99% | two nines | about 3 days 15 hours 36 minutes |
| 99.5% | two and a half nines | about 1 day 19 hours 48 minutes |
| 99.9% | three nines | 8 hours 45 minutes 36 seconds |
| 99.95% | three and a half nines | 4 hours 22 minutes 48 seconds |
| 99.99% | four nines | 52 minutes 34 seconds |
| 99.995% | four and a half nines | 26 minutes 17 seconds |
| 99.999% | five nines | 5 minutes 15 seconds |
| 99.9999% | six nines | about 32 seconds |
Five nines gets quoted constantly as the gold standard for critical infrastructure — telecoms switches, payment rails — but it's worth noticing how little slack it leaves: barely five minutes a year across every dependency, not just the headline service.
How to Convert an Outage Into an Uptime Percentage
The forward direction (percentage → downtime) is the easy half. The other direction comes up just as often: you had an outage, and you need to report what percentage uptime that represents — for a postmortem, an SLA breach claim, or just your own dashboard.
The maths is the mirror image of the table above: divide the downtime by the length of the period, subtract that fraction from 1, and multiply by 100. A 42-minute outage in a 30-day month, for instance, works out to roughly 99.903% uptime for that month — comfortably inside a 99.9% SLA, but worth checking against the exact contractual period length rather than eyeballing it.
For odd, non-calendar windows — "we were down from 14:32 to 15:14 on the 12th" — a fixed day/week/month bucket doesn't apply cleanly. A custom date-range mode that takes an exact start and end timestamp plus the outage duration avoids rounding a postmortem window into the nearest calendar period.
Combined SLA for Dependent Services: Why You Can't Just Average
This is the part most SLA discussions skip, and it's where the real mistakes happen. If your application depends on a database, a CDN, and an auth provider — and any one of them failing takes the whole app down — the application's actual achievable uptime isn't the average of the three SLAs. It's their product.
Two services each individually rated at 99.9% don't combine to 99.9%. They combine to:
0.999 × 0.999 = 0.998001 → 99.8001% ≈ 99.8%
That's roughly 17.5 hours of downtime a year — about double what either service alone would suggest — simply because both need to be up at the same time, and each has its own independent chance of failing.
Add a third hard dependency and it compounds further. Three services individually rated at 99.9%, 99.99%, and 99.95% combine to:
0.999 × 0.9999 × 0.9995 ≈ 0.998401 → 99.84%
— about 14 hours of downtime a year, worse than any single link in the chain, even though two of those three services individually look excellent on paper.
This only applies to serial, hard dependencies — where the whole system genuinely fails if any one component fails. It does not apply to redundant or failover (parallel) architectures, where a single component going down doesn't take the system with it. Multiplying availabilities for a redundant setup would understate its real resilience, not overstate it — different maths for a different architecture.
Comparing Vendor SLAs Side by Side
The last piece worth flagging: when you're comparing cloud providers or hosting plans — "AWS's 99.99% vs this vendor's 99.95%" — don't stop at the headline percentage. Line up the actual downtime figures for the periods that matter to you (monthly is usually the one that maps to billing credits), and check both vendors are quoting the same year/month convention. A 0.04 percentage-point gap sounds trivial until you see it's the difference between about 4 minutes and about 22 minutes of permitted downtime a month.
Try It Yourself
Doing any of this arithmetic by hand is fiddly and easy to get subtly wrong — particularly the averaging-vs-multiplying trap above, which even experienced engineers reach for under time pressure. Skojio's SLA uptime calculator covers all five directions in one tool: forward (percentage → downtime), reverse (outage → percentage), a custom date-range mode for postmortems, a compound/chained calculator that multiplies dependent services correctly, and a side-by-side comparison table for vendor SLAs — with the year/month convention exposed as an explicit, switchable toggle rather than silently hardcoded. It runs entirely in your browser: nothing you type ever leaves your device.
If SLA maths brought you here, a few of Skojio's other free browser-based infra tools are worth a look too: the Chmod Calculator for the other everyday Linux/Unix arithmetic, the Cron Expression Helper for scheduling maintenance windows around whatever downtime budget you've got left, and the Timezone Helper for making sure "this month" means the same thing to everyone on a distributed team.
Top comments (0)