99.9% vs 99.99% uptime: SLAs, SLOs and what downtime really costs

A 99.9% uptime guarantee allows about 8 hours 45 minutes of downtime a year, or roughly 43 minutes a month. Move one digit to 99.99% and that shrinks to about 52 minutes a year — around 4 minutes 19 seconds a month. That tenfold swing for one extra "9" is why the number in an SLA is worth reading carefully, and why the percentage, the target you actually operate to day to day, and what an outage really costs you are three separate questions. This post walks through all three.

If you're comparing hosting or managed-service options before you get to the SLA fine print, our guide to cloud servers, VPS and managed hosting is the place to start.

99.9% uptime and beyond: how much downtime each tier actually allows#

The table below assumes a 30-day month and a 365-day year — real months vary slightly, so treat these as close approximations, not exact figures for a specific month.

Two things matter more than the raw numbers. First, most SLAs measure monthly, not annual, availability — a single bad afternoon can breach a monthly 99.9% target even if the rest of the year is spotless. Second, going from 99.9% to 99.99% ("three nines" to "four nines") isn't a small upgrade — it's an order-of-magnitude reduction in acceptable downtime, and it usually requires an order-of-magnitude increase in redundancy to actually achieve.

SLA vs SLO vs SLI: three different things#

These terms get used interchangeably, but Google's Site Reliability Engineering book draws a clean line between them:

• SLI (service level indicator) — a measurement, like "percentage of requests that returned successfully in the last 5 minutes."
• SLO (service level objective) — a target for that measurement, like "99.9% of requests succeed, measured monthly." This is what your team actually operates to.
• SLA (service level agreement) — the SLO turned into an external promise with a consequence attached, usually a service credit, if you miss it.

The SRE book's own shorthand is useful: if there's no explicit consequence for missing the number, you're looking at an SLO, not an SLA. Most internal engineering targets are SLOs. The number in your hosting contract is an SLA.

What SLAs typically exclude#

Every SLA we've reviewed carves out certain causes of downtime from the calculation. Reading the exclusions tells you more than the headline percentage. Common carve-outs, drawn from AWS's and OVHcloud's published terms, include:

• Scheduled maintenance announced in advance.
• Force majeure and events outside the provider's reasonable control.
• Your own configuration, code or equipment — an SLA covers the provider's infrastructure, not your application's bugs.
• Third-party and upstream network issues beyond the provider's own border router or demarcation point.
• Security incidents you're partly responsible for, such as not responding to a flagged compromised resource.

None of this is unusual or hidden — it's standard practice across the industry — but it does mean the real-world protection an SLA gives you is narrower than "the service will be up 99.9% of the time, full stop."

How service credits work, and their limits#

Two concrete examples, current as at September 2026: AWS's Amazon EC2 SLA and OVHcloud's VPS SLA both use the same shape of tiered credit — showing this pattern is common industry practice, not unique to one vendor.

AWS commits to at least 99.99% at the region level (instances spread across two or more availability zones) or 99.5% for a single instance. OVHcloud's VPS commitment is 99.9%. In both cases, the credit is a percentage of that service's fees for the affected month, capped at 100% of the bill — not compensation for lost revenue, refunded customers or the hours your team spent responding. Treat SLA credits as a partial refund for a broken promise, not as insurance against the cost of downtime.

Composite availability: why dependencies multiply#

If your application depends on several independent services in series — your server, your database, a third-party payment API — and each is available 99.9% of the time on its own, the combined availability is not 99.9%. It's the product of all of them:

0.999 × 0.999 × 0.999 ≈ 99.70%

That's roughly 26 hours of potential downtime a year instead of the 8 hours 45 minutes any single 99.9% component implies on its own — because the whole chain is only as available as all of its links being up at the same time. This is the practical reason to minimise hard dependencies in your critical path, add retries and graceful degradation where a dependency is non-essential, and treat the advertised uptime of any one component as an upper bound on what the whole system can achieve, not a guarantee of it.

It's also why the minutes matter more than the percentage once an incident is under way. A team that knows who declares an incident, who talks to customers and what the first 15 minutes look like will claw back real minutes against an SLO; a team improvising for the first time during an outage will lose them. See our guide to incident response runbooks and on-call for how to set that up before you need it.

A simple way to estimate what downtime costs you#

Skip industry-average downtime-cost statistics — they vary wildly by business and are easy to misapply. Instead, build the number from your own figures:

Direct cost per hour of downtime ≈ (revenue that stops flowing per hour) + (staff hours spent responding × hourly cost) + (any contractual credits you owe your own customers for that outage)

Then multiply by expected downtime hours at a given SLA tier (from the table above) to compare tiers on a like-for-like basis. Add a qualitative line for cost you can't easily put a number on — customer trust, support load in the following days, reputational impact of a public outage — and weigh that alongside the direct figure rather than trying to force it into the formula. This gives you a defensible reason to pay for a higher availability tier (or not), instead of picking a number because it sounds safer.

Why a managed provider's SLA can't beat its upstream infrastructure#

A managed hosting or DevOps provider's SLA is a promise about outcomes, but the outcomes still depend on real infrastructure underneath — power, networking, physical hardware, a data centre. If that underlying infrastructure realistically delivers, say, 99.95% availability, a provider built on top of it can promise a higher number on paper and cover the gap financially with credits, but it cannot make the underlying infrastructure more available than it actually is. The technical ceiling is set by the upstream provider; anything promised above that ceiling is a financial guarantee, not a technical one.

This is one reason we're upfront that Inventure resells and manages infrastructure from OVHcloud rather than owning data centres or network hardware ourselves — our own commitments sit on top of, and are bounded by, OVHcloud's published SLAs for the products we use. See our SLA for the actual terms that apply, rather than treating any percentage in this article as a promise from us.

What to do next#

Work out your own downtime-cost formula before you shop for an uptime tier — it tells you whether 99.9% is plenty or 99.99% is worth paying for. If you want backups and incident response designed around a specific RTO rather than a marketing number, see how we approach monitoring and incident response, and pair this with our guide to backups that actually restore so your recovery time matches what you've promised.