99.99% vs 99.9% Uptime: What the Nines Mean for Your Bill

August 14, 2026

The gap between 99.9% and 99.99% uptime is one decimal place and a tenfold change in what your provider owes you. At 99.9%, a service can be down 8.77 hours a year before the SLA is breached. At 99.99%, the allowance is 52.6 minutes. Same provider, same month, same outage: a 30-minute incident is a breach under one agreement and business as usual under the other. Which nines you are actually under is decided less by your provider than by how you deploy, and that choice sets both your real exposure and the size of the credit you can claim when something breaks.

The math behind the nines

Every uptime percentage is a budget of allowed failure. A year has 525,600 minutes, and the percentage is what remains after the downtime comes out. The table below is the version worth keeping on a sticky note.

Each extra nine cuts the budget tenfold. Going from 99.9% to 99.99% does not mean "a bit more uptime"; it means your monthly allowance drops from 43.8 minutes to 4.4. One unplanned 20-minute deployment regression in the wrong week and the 99.99% budget is gone for the month, while the same event barely dents a 99.9% allowance.

The nines you actually get depend on how you deploy

Here is the part that surprises people. All four big providers advertise 99.99% somewhere, and every one of them attaches architecture conditions to it.

AWS is the most honest about the trade. Its compute SLA promises 99.99% at the region level only when all your running instances sit across two or more Availability Zones, and drops to 99.5% for an individual instance. That 99.5% is 3.6 hours of allowed downtime a month: a full working afternoon of a single server being gone, and no credit is owed. Azure and Google run the same ladder in slightly different clothes. DigitalOcean is the outlier, promising 99.99% per Droplet with no multi-zone requirement, which is the most direct commitment of the four on paper.

The most useful sentence in any cloud SLA: the nines are a property of your deployment, not your provider. Run one instance and the 99.99% promise evaporates.

Two consequences follow. A single-instance setup is not a 99.99% deployment, whatever the product page says. And because the top tiers breach so easily, almost every real outage clears the bar: a 99.99% commitment is broken by 4.4 minutes of downtime in a month, and most incidents that get a status-page entry last longer than that.

What a breach is worth

When the monthly uptime percentage falls below the commitment, the provider owes you a service credit calculated on what you paid for that service in the affected region that month, not on your whole invoice. The current ladders:

Two wrinkles worth knowing. AWS's instance-level SLA carries its own 10/30/100 ladder below 99.5%, so even a single instance earns a credit once it crosses 99.5%. GCP's single-instance ladder is looser: 10% down to 95%, 25% down to 90%, 100% below 90%. And AWS stops charging for any instance unavailable for more than six minutes of a clock hour, automatically, with no claim needed.

Now the money math. Say you spend $10,000 a month on EC2 in one region, spread across two Availability Zones, so the 99.99% commitment applies. A 30-minute incident in a 30-day month puts you at 99.93%. That is below 99.99% and above 99.0%, so the credit is 10% of the $10,000: one incident, one support case, $1,000 back on a future bill. Run the same 30 minutes against a 99.9% commitment, which is what a single-instance setup or most storage services carry, and 99.93% sits comfortably inside the allowance. No breach, no credit, no recourse. The outage cost you the same either way. Only the contract's decimal place differs.

Credits pay you back for a broken promise, not for the damage. A 30-minute outage on a checkout flow costs far more than 10% of the hosting bill, so treat the credit as a floor, not compensation.

The fine print that eats the nines

Four clauses decide most claims before you file them.

• Measurement. GCP counts only consecutive full minutes of downtime; a month of 40-second blips is a perfect month on paper. AWS measures the region-level SLA per region and the instance-level SLA per instance.
• Wording. AWS commits to "commercially reasonable efforts" rather than a guarantee. The phrase matters less than it sounds, because the credit schedule is mechanical once the percentage crosses a tier.
• Exclusions. Scheduled maintenance announced in advance, force majeure, and anything caused by your own configuration are all out. Providers keep maintenance windows wide precisely to protect the nines.
• Windows. AWS wants claims by the end of the second billing cycle after the incident. GCP requires notification within 60 days of becoming eligible. DigitalOcean gives two billing cycles. None of them will remind you.
• Payout. Credits land on future bills, not refunds. AWS skips credits under $1, and GCP caps a month's credits at that month's bill for the affected service.

Every one of these clauses is documented, none of them is in the marketing material, and together they are why most teams treat SLA math as a rounding error. It is not. A single 99.99% breach a year on a $10,000 monthly bill is a four-figure credit that costs maybe an hour of paperwork.

Here is the one thing to do today. Open the SLA for the service you spend the most on, note the commitment percentage and the architecture it requires, and check that your deployment qualifies for it. Write down your monthly allowance: 4.4 minutes if it is 99.99%, 43.8 if it is 99.9%. That number is your breach budget. The next time an incident eats more than half of it, start the claim file while the evidence is fresh. Providers count on you never knowing the number. Knowing it is the whole game.