SLA, SLO, SLI, plainly: who pays for the fifth nine

Two teams, one incident channel. “Your API is flaky again.” - “Everything is green on our side.” Both sentences are unfalsifiable, which is why this argument never ends: nobody has said a number yet.

Reliability disputes are rarely engineering problems. They are contract problems, and the contract has three letters in it. In DORA’s 2021 study, 52% of teams reported using SRE practices to some extent - and only 10% of even the elite performers had fully implemented every practice surveyed. “To some extent” is precisely the state where the dashboards exist and the contract does not.

(A disambiguation, since the acronym is triple-booked. Here DORA is DevOps Research and Assessment, Google’s research program. For your compliance colleagues it is the Digital Operational Resilience Act, Regulation (EU) 2022/2554. For your kids it is an animated explorer with a backpack. This post is about the first one - do not cite the second in a retro, and do not cite the third in an audit.)

Three letters, three audiences

The letters are not synonyms. They are three documents, owned by three different rooms.

SLI is the measurement. A ratio: good events over valid events, on a window. The share of requests that returned 2xx. The share that finished under 300 ms. Engineers own it, because only engineers can say what “good” and “valid” mean at the edge of the system.

SLO is the target. An internal goal for that ratio: 99.9% of requests succeed, rolling 30 days. Engineering and product own it together, and “together” is not a courtesy. The SRE Workbook is explicit: the arrangement works when product accepts the threshold, developers agree to act when the budget runs out, and operations can defend the objective as realistic - and if any of the three does not sign, you iterate until they do.

SLA is the promise with money attached. The Workbook’s definition is the most honest one in print: a business contract that “comes into effect when your users are so unhappy you have to compensate them in some fashion”. Legal and sales own it. Engineers appear in it only as the people who get paged.

One rule ties the three together: the external promise stays at least one nine weaker than the internal target. Sell 99.5%, run at 99.9%. The gap is where operational reality lives - the deploy that went sideways, the region that blinked - without every wobble becoming a breach of contract.

The price list

A nine is not a number, it is a budget line. The short windows:

availability   day       week      30 days
99%            14m 24s   1h 41m    7h 12m
99.9%          1m 26s    10m 5s    43m 12s
99.95%         43s       5m 2s     21m 36s
99.99%         8.6s      1m        4m 19s
99.999%        0.9s      6s        26s

And the long ones - quarter, half-year, year:

availability   90 days   180 days  365 days
99%            21h 36m   1d 19h    3d 16h
99.9%          2h 10m    4h 19m    8h 46m
99.95%         1h 5m     2h 10m    4h 23m
99.99%         12m 58s   25m 55s   52m 34s
99.999%        1m 18s    2m 36s    5m 15s

Read it two ways. Down a column is what a nine buys. Across a row is why the window matters: the same 99.99% that forgives a minute a week forgives less than nine seconds a day.

Each step right costs roughly ten times the previous one: 99.9 to 99.99 is the jump from “restart it when it breaks” to multi-region failover, automated recovery, and a pager staffed at 4 a.m. AWS’s reliability guidance adds the quieter costs: past a certain goal the set of dependencies you may even use shrinks, testing hardens, and innovation slows because every deploy must move carefully. So when someone across the table asks for four nines, the engineering answer is not “no”. It is the price list, plus one question: who is paying - in dollars and in sleep?

The same letters, two rooms

For the engineering room, the letters are instruments. The SLI is the truth serum: it replaces “feels slow” with a ratio. The SLO is the tripwire that decides when feature work yields to stability work. The SLA is the boundary condition - a promise someone else made, which the pager enforces.

For the business room, the same letters read differently. The SLI is invisible; it never leaves the dashboards. The SLO is risk appetite written as a number: how much failure the company is willing to buy in exchange for shipping speed. The SLA is a sales asset and a liability at once - it closes enterprise deals, and it prices exactly what a bad month costs.

Every nine after the decimal is real money, roughly an order of magnitude per step, and a nine is neither good nor bad on its own - it is justified or it is not. AWS’s availability tiers say this out loud by pairing nines with application classes: batch pipelines at 99%, internal tools at 99.9%, online commerce at 99.95%, video delivery at 99.99%, ATM transactions at five nines. A payments checkout at 99.99% is a defensible invoice. An internal wiki at 99.99% is a bonfire of on-call salaries. The letters exist so the two rooms can have this argument with numbers instead of adjectives: engineering brings the price list, business brings the revenue at stake, and the SLO is the line where they meet.

Error budget, the shared currency

Flip the SLO around and you get the error budget: 1 - SLO. For 99.9% on 30 days, that is 43 minutes of allowed failure a month. Not a shameful reserve - a budget, meant to be spent on releases, migrations, and experiments.

The budget’s real job is translation. It turns two unwinnable arguments into two decidable ones.

“Stop deploying, you keep breaking prod!” becomes: we are burning budget at 8x, and the policy we both signed pauses releases until the budget recovers.

“This bug is harmless, ship it” becomes: this bug eats 15% of the monthly budget, 30% is left, so it gets fixed before release.

The load-bearing phrase is “we both signed”. An error budget policy nobody signed is a dashboard everybody ignores.

Burn rate, the exchange rate

Burn rate is how fast, relative to the SLO, the service consumes its error budget. Burn rate 1 spends exactly the whole budget by the end of the window. Burn rate 14.4 on a 30-day window spends 2% of the monthly budget per hour - the whole budget in about two days.

The Workbook’s canonical alerting setup fires only when two windows agree:

alert    burn rate   windows       spent
page     14.4x       1h + 5m       2%
page     6x          6h + 30m      5%
ticket   1x          3d + 6h       10%

The two windows are the whole point. The long one proves the burn is real and not a spike; the short one silences the alert as soon as the bleeding stops. Slow steady burns still get caught - by the ticket row, before they get paged about. And for low-traffic services the Workbook’s advice is not “tune the thresholds per service”: generate synthetic traffic, aggregate related services, or admit the SLO is measuring the wrong thing.

The multiplication tax

Availability composes by multiplication, and multiplication only goes down. Five services at 99.9% each, chained in series: 0.999^5 = 99.5% - about 3.6 hours of downtime a month, in a chain where every single link keeps its own promise.

AWS’s Well-Architected guidance states the rule without decoration: with hard dependencies, the invoking system’s availability is the product of the dependent systems’ availabilities. Three services designed for 99.99% compose to 99.97%. Your ceiling was set the day the architecture diagram was drawn, not the day the pager went off.

The same arithmetic offers the way out. Independent redundancy multiplies failure rates instead of availabilities: two independent 99.9% components in parallel give 99.9999% - AWS’s shortcut is that you may literally add up the nines. So the architect has two levers. Turning hard dependencies into soft ones - cache, circuit breaker, sane defaults, async retry - adds effective nines without new hardware. Redundancy buys them with it, but only where the dependency truly must stay hard.

Three ways to lie to yourself

The watermelon. Green outside, red inside: the health check returns 200 while real users hit DNS, CDN, or TLS failures the check never sees. The cure is measuring where the users are - SLIs on user-facing endpoints, synthetic probes from outside your network, real-user monitoring - and a periodic check that the SLI still moves together with the business metrics.

The copied SLA. Your cloud provider’s 99.99% is not your 99.99%. Your stack is a product of several managed services and your own code, and that product sits below every number on any one pricing page. The exclusions buried in the provider’s SLA do not transfer to your customer contract either.

The round number. 100% is not a target. Its error budget is zero, so nothing may ever be deployed, migrated, or tried. Worse, users quietly build on top of “it never fails” - and the first real failure lands on a dependency you never knew you had.

The contract in one line

SLI is what you measure. SLO is what you aim at. SLA is what you owe.

Keep them in that order, keep a nine between the last two, and keep the budget where both teams can see it. Then “your service is flaky” stops being an accusation and becomes a number - and the fifth nine gets bought only when the person asking for it also signs for the pager.

Reading

• Implementing SLOs and Alerting on SLOs - Google SRE Workbook, chapters 2 and 5
• Service Level Objectives - Google SRE Book, chapter 4: the 2016 original the Workbook builds on
• The Calculus of Service Availability - ACM Queue, 2017: the dependency math, from the people who run five nines
• Availability - AWS Well-Architected, Reliability Pillar
• OpenSLO - an open specification for declaring SLOs as code
• Accelerate State of DevOps 2021 - DORA
• Implementing Service Level Objectives - Alex Hidalgo, O’Reilly, 2020
• Regulation (EU) 2022/2554 - the other DORA, strictly for your compliance team