Each nine divides the downtime by ten and, roughly, multiplies the engineering by the same. The first ones are nearly free — a single well-run server gets you two. The last ones are somebody's whole career.
If your service needs a database, an auth provider and an object store, and each is up 99.9% of the time, your service is not up 99.9% of the time. It is up 0.999 × 0.999 × 0.999 = 99.7%, which is 26 hours a year rather than 8¾. Three excellent dependencies produced a mediocre service, and nobody did anything wrong.
This is why the rule’s own failure mode matters more than the rule. Chasing four nines on top of a three-nines dependency is not expensive — it is impossible. The cost curve does not steepen, it goes vertical, and the only ways past it are removing the dependency, making it optional, or duplicating it.
Two copies of a 99.9% component give 99.9999% — if they fail independently. They rarely do. They share a region, a deployment pipeline, a certificate, a configuration push, a dependency of their own. Correlated failure is the normal case, and it is why real multi-instance systems never reach the number the arithmetic promises.
Treat the redundancy figures here as a ceiling nothing reaches, in exactly the way the dependency figures above are a floor you cannot rise above.
A published availability figure is not an engineering commitment. It is the threshold below which the provider owes you a service credit — typically a percentage off next month's bill, capped, and usually only if you notice and claim it within a window.
Which means the compensation is bounded by what you pay them, and your loss is not. An hour of downtime that costs your business ten thousand pounds is refunded with a few pounds off a cloud bill. The SLA prices the provider's risk, not yours.
Two more details worth knowing. The measurement window is usually the calendar month, so February gives you fewer absolute minutes than March at the same percentage — the selector above lets you see the difference. And what counts as "down" is defined by the provider: partial degradation, elevated error rates and slow responses frequently do not qualify, even when they are indistinguishable from an outage to your users.
You promise 99.9% and you depend on a managed database at 99.95%, an identity provider at 99.9% and an object store at 99.9%. Your own code is flawless — call it 100%.
Multiply: 0.9995 × 0.999 × 0.999 = 99.75%. That is 22 hours a year before you have written a line of your own. Your 99.9% promise allowed 8.8 hours, so you are over budget by a factor of two and a half and the fault is nowhere in your system.
Two copies of the identity provider, failing independently, would be worth 99.9999% between them and take the stack to 99.85%. But they are the same provider, in the same region, behind the same certificate authority: assume a fifth of their failures are shared and the pair is worth 99.98% — under four nines where independence promised six — and the stack lands at 99.83%. A whole second copy bought back eight hundredths of a percent. The honest fix is not redundancy — it is making the dependency optional, so a failed identity check degrades the checkout instead of stopping it.
Because availabilities multiply and every one of them is below 1. Adding a component can only take the product down. The only operations that raise it are removing a dependency, making it optional, or putting a second copy in parallel — and the last one only helps to the extent the copies fail for different reasons.
The downtime your target allows, treated as a spending account. At 99.9% you have 43 minutes a month. An incident that costs 20 of them has spent half the budget, and the useful question afterwards is not "was that acceptable" but "what will we not ship this month to protect the rest of it". It turns a reliability target into a trade you can actually make.
It is a hundred times better and roughly a hundred times harder. 99% allows 3.65 days a year, 99.99% allows 53 minutes. Each nine divides the downtime by ten, which is why the ladder on this page is drawn on a logarithmic scale — on a linear one the top four rungs would be indistinguishable from the axis.
No. It is the threshold below which you can claim a service credit, usually a small percentage off the next bill, usually only if you notice and claim within a window. It bounds the provider's liability, not your loss, and what counts as "down" is defined by them — elevated error rates and slow responses often do not qualify.
Going from 99% to 99.9% removes nine tenths of your downtime budget: from three and a half days a year to under nine hours. The next nine takes you to 52 minutes. The arithmetic is trivial; the engineering behind each step is not, which is why the rule pairs them.
Every service you cannot work without multiplies into your availability. Three 99.9% dependencies put a hard ceiling of 99.7% over you before you have written a line of code, and no effort on your side lifts it.
SLA credits are almost always assessed per calendar month, so the same percentage buys fewer absolute minutes in February than in March. At 99.9% that is 40 minutes against 45: worth knowing if you are close to the line.
Two copies give you four nines from two, provided they never fail together. Shared regions, shared deploys, shared certificates and shared config pushes mean they routinely do. The paper figure is a ceiling, not a forecast.
Providers define “unavailable” narrowly. Elevated error rates, slow responses and degraded features often fall outside it, even when your users cannot tell the difference from a full outage. The measured number and the experienced one are not the same number.
An SLA caps the provider’s exposure at a slice of your bill. It does not compensate your revenue, your reputation or your weekend. Treat the percentage as a design input, and never as insurance.
Releases in which this page changed, newest last. Derived from the archived copy of every release, not from notes written afterwards — so it reflects what actually shipped. Site-wide passes are left out; they are in the full changelog.