What Does 99.9% Uptime Actually Mean?

An SLA is a downtime budget

Percentages near 100 all look alike. The minutes behind them differ by orders of magnitude, which is the only reason to convert.

Target	Per year	Per 30-day month
99%	87h 36m	432 min
99.5%	43h 48m	216 min
99.9%	8h 46m	43.2 min
99.95%	4h 23m	21.6 min
99.99%	53m	4.3 min
99.999%	5m	0.4 min

Three nines sounds close to perfect. It permits 43 minutes a month — which is one bad deploy.

The third nine is where the problem changes

Each additional nine divides the budget by ten. That sounds incremental. It isn't.

Going from 99.9% to 99.99% takes the annual allowance from 8 hours 46 minutes to 53 minutes.

Fifty-three minutes a year does not survive a single incident where somebody is paged at 3am, wakes up, connects, and starts diagnosing. The human response alone can spend the entire annual budget before anyone has understood the problem.

So anything past three nines has to be handled by automatic failover, not by people being more careful. It's an architecture decision with an architecture budget attached — not an operations decision about trying harder.

That's the single most useful thing to know before agreeing a number in a contract.

The month is what gets billed

Most commercial SLAs are measured and credited monthly, and that has a consequence worth understanding: a year of excellent months does not offset one bad one.

An outage on the last day of a month is a different commercial event from the identical outage a day later.

If you're setting an internal reliability target rather than meeting a contract, the year is often the more honest period — it stops you gaming a monthly boundary.

Credits refund fees, not losses

This is the most important thing to understand about an SLA, and it's the part people assume rather than read.

When a provider misses its target, the remedy is almost always a percentage refund of what you paid them for that period. A service costing $100 a month might credit you $10 or $20 for an outage that cost your business considerably more.

An SLA is a statement of intent backed by a refund policy. It is not insurance, and it doesn't meaningfully transfer the risk of an outage to the provider.

If downtime genuinely costs you serious money, the answer is redundancy you control — not a better percentage in someone else's contract.

They probably don't count it the way you do

Contracts commonly exclude:

• Scheduled maintenance windows
• Anything the provider attributes to your configuration
• Problems outside their network

And availability is normally measured from their monitoring, not from where your users are.

Which means a service can miss every internal target you care about while comfortably meeting the SLA as written. The only way to know what your users actually experienced is to measure it yourself, from outside, and treat the provider's figure as a separate commercial number.

Decide how you'll count a partial outage — before you have one

A service that's up but too slow to use, or working for 90% of users, is not a clean binary.

The temptation is always to resolve that ambiguity generously after the fact. Agreeing beforehand what counts — a latency threshold, an error-rate threshold, a proportion of users affected — is worth more than any figure this tool produces.

It's the definition, not the arithmetic, that decides whether you met the target.

On the numbers themselves

A month here is 30 days and a year is 365 — the conventional figures used in nearly every SLA table, not a calculation for your specific calendar.

The difference is a couple of percent and it never changes a decision. If you're close enough to a threshold for the length of February to matter, the problem isn't the arithmetic.

Some contracts do specify actual calendar days, so it's worth checking which yours uses when a credit is at stake.