What 99.9% Uptime Actually Buys You: Reading an SLA Like an Engineer

What 99.9% Uptime Actually Buys You: Reading an SLA Like an Engineer

A vendor proposal lands with "99.9% uptime SLA" printed near the top, and it reads like a promise. Before you sign anything, translate the percentage into hours.

That's the real budget behind each marketing number, worked out in full here. Three nines still allows almost nine hours of outage a year. If your checkout page or booking system can't survive a 40-minute afternoon outage once a month, the number on the proposal was never the thing protecting you.

The next question is what happens once that budget runs out.

How SLA credits actually work

Read a cloud SLA and the mechanism is almost always the same: a tiered service credit, not compensation. AWS defines Amazon EC2's Monthly Uptime Percentage as 100% minus the share of the month spent unavailable, then pays credits on a sliding scale. It pays a 10% credit if uptime falls below 99.99% but stays at or above 99.0%, and 30% if it drops below 99.0% but stays at or above 95.0%. And it pays 100% if uptime falls below 95.0% — full tier table here.

Google Cloud's Compute Engine SLA runs the same shape. Monthly Uptime Percentage is total minutes minus downtime minutes divided by total minutes. Credit tiers pay 10% for 99.00–99.99% uptime, 25% for 95.00–99.00%, and 100% below 95.00%. Credits arrive as a bill credit, capped at that month's charge for the affected service.

Notice what's being credited: a percentage of your bill, not a percentage of your loss. Pay $200 a month for compute, trigger the top tier, and you get $200 back — even if the outage cost you a full day of lost bookings.

The exclusions that quietly swallow the guarantee

Every SLA I've read carves out the same categories before the percentage even applies. AWS's EC2 SLA states plainly that it does not cover unavailability caused by factors outside AWS's reasonable control. Nor does it cover unavailability from the customer's own actions or inactions, or from the customer's own equipment, software, or technology — see the exclusions.

Google's Compute Engine SLA excludes pre-general-availability features, anything the documentation separately marks as out of scope, and factors outside Google's reasonable control. It also excludes the customer's own or third-party software and hardware, and anything tied to a quota you exceeded.

Read those clauses as a buyer. A misconfigured DNS record, a broken third-party payment API, a plugin you installed: all of it sits outside the guarantee by design. Microsoft's own guidance on reading SLAs names the remaining gap directly: service credits are typically a percentage of the monthly fee. In their words, "credits don't cover lost revenue, customer attrition, or reputational damage" — the entire business impact of an outage, sitting outside the contract you just signed.

How to read an SLA like an engineer, not a shopper

Skip the headline percentage on a first read. Go straight to the definitions: how is downtime measured, over what window, and does one failed request count the same as ten thousand? Time-based measurement (was the service unavailable this minute) and request-based measurement (what fraction of requests failed) produce different numbers from the same incident. The fine print decides which one applies to you.

Then check what happens when your system depends on more than one vendor's SLA at once.

Multiplying those four percentages together for a "combined" number is a common shortcut. Microsoft's reliability guidance calls it out as unreliable: it assumes independent failures and ignores that each vendor's SLA carries its own definitions and exclusions. A payment API outage isn't covered by your CDN's credit, and your database vendor's SLA says nothing about the app server sitting on top of it.

There's no single number to shop for here — only a chain of separately negotiated, separately excluded contracts.

Why five nines is marketing for most SMEs

Five nines sounds like the safest number to ask for, but for almost every SME it's the wrong target. Google's SRE Workbook makes the tradeoff explicit. As reliability climbs from 99% toward 99.9% toward 99.99%, each extra nine costs disproportionately more while the marginal value to users approaches zero. Retail customers can't tell 99.9% from 99.999%, but they can tell the difference between a five-nines budget and the roadmap it consumed to get there.

The same chapter names a second cost: change is the leading cause of outages, so a team chasing 100% reliability eventually stops shipping. Deploys, patches, scaling events all become risk to a target with no room to absorb any. A system frozen to protect its uptime number has stopped improving, which is its own kind of failure.

Error budgets: the practical alternative to chasing nines

Think of an error budget like a sick-leave allowance. You don't have to try to spend every day of it, but pretending it doesn't exist doesn't help either. The only real decision is when to spend it.

Google's SRE book gives this tradeoff a name and a number: an error budget is 100% minus your SLO. Set a 99.9% availability target and your error budget is the 0.1% of time you're allowed to be down. Spend it on deploys, spend it on an incident, spend it on a risky migration — your call.

What the budget does, in the book's own framing, is remove the politics from the negotiation between reliability and product development. It replaces an endless argument over how careful to be with one shared, spendable number.

For a small engineering team, this is more useful than any vendor SLA. It's yours to set and spend. And it forces the real question — how much downtime can this business absorb — instead of letting a marketing percentage answer it for you.

A buyer's checklist before signing

• Convert the promised percentage into your own downtime tolerance in hours, using the table above, not the marketing copy.
• Read the exclusions clause before the credit tier table. That's where most of the guarantee actually lives.
• Find the claim-filing deadline. Most SLAs require you to report the outage within a set window, or you get nothing automatically.
• Ask what's outside the SLA's scope entirely — preview features, specific APIs, specific pricing tiers often aren't covered at all.
• Decide what redundancy you're building yourself. No SLA compensates you for the business you lost; that risk is yours to design around.

Where this leaves an SME buying hosting or SaaS in Indonesia

Use the SLA for what it actually is: the vendor's own risk assessment, priced into a credit tier they're comfortable defending. It's not a promise that the service will stay up, and not a plan to make you whole if it doesn't.

A single vendor with a big number and no redundancy plan is still a single point of failure. Build your own error budget from what the business can tolerate, then design and monitor toward that number instead of shopping for someone else's.