SLI / SLO / SLA: A Measurement, a Target, a Contract

The previous post said error budget = 1 − SLO. But what is an SLO? And how does it differ from the other two abbreviations almost everyone mixes up — SLI and SLA? Without telling these three apart, there’s no talking about reliability. Remember it in one line first: the SLI is the number you “measure”, the SLO is the target you “aim for internally”, the SLA is the contract you “promise customers”.

A measurement, a target, a contract

The three nest outward, and each threshold is looser than the last:

The SLI is what you actually measure (99.95%); the SLO is the internal target you aim for (99.9%); the SLA is the contract with customers (99.5%, breach pays out). The SLA is deliberately a notch looser than the SLO, and the stretch between them is the safety buffer you keep for yourself

Taken apart:

SLI (Indicator): the reliability number you actually measure, e.g. “99.95% of requests succeed”. It answers “how reliable are we right now?” — the raw material for monitoring and for computing the error budget.
SLO (Objective): the internal target you set on the SLI, e.g. “request success rate ≥ 99.9%”. It answers “how reliable is reliable enough?” — error budget = 1 − SLO comes from here.
SLA (Agreement): your promise to customers, with a price for breaking it (refunds, compensation), e.g. ”≥ 99.5%, or this month’s fee is refunded”. It answers “what happens if we don’t make it?”

The key is the ordering: the SLA is always looser than the SLO. Because if the threshold you promise externally (SLA) were as high as your internal target (SLO), then the moment you miss the SLO you’re in breach and paying out. Leave a buffer, so you get the alarm at “not yet in breach, but time to worry” — feel the pain inside before the customer does.

What makes a good SLI

Of the three, the SLI is the root — SLO and SLA are thresholds built on top of it. So defining a good SLI matters a great deal. Good SLIs almost all have the same shape: “good events” as a proportion of “valid events”:

A good SLI is the ratio "good events / valid events", and it must be something users actually care about — did their request succeed? Was it fast enough? Was the result right? Is the data fresh enough? Internal metrics like CPU and memory aren't SLIs, because users never feel them

The most common mistake is using “what’s easy for you to measure” as the SLI — a pile of CPU, memory and disk numbers. But those are causes, not what the user experiences. An SLI has to follow the user’s journey: did the request they sent succeed? Did it come back fast enough? That forces you to define “good” from the user’s point of view, not the datacenter’s.

How to set an SLO, and why the SLA has to be looser

A few points for setting SLOs: don’t set 100% (the previous post covered why — too expensive and imperceptible); express it as “time window + percentage”, e.g. “over the past 28 days, 99.9% of requests succeed”; and work backwards from user experience — a little above the line where users start complaining is a reasonable SLO.

For the SLA, remember two things: not every service needs an SLA (internal services usually need only an SLO); and the SLA is always looser than the SLO — the SLO is your own early alarm, forcing you to turn back and fix things before an actual breach costs money. It all comes back to the error budget: set the SLO, and 1 − SLO is the budget you can spend over the period, while the measured SLI tells you how much you’ve spent. The SLI measures the present, the SLO sets the target, the error budget governs the pace, the SLA holds the floor — four things on one thread.

Reflections

”Strict inside, loose outside” is the most mature move I know

The SLA being looser than the SLO may look redundant at first glance, but it hides very mature thinking: set yourself a higher standard than what you promise externally, as an early alarm. Reacting only when the customer’s line (the SLA) is crossed is already too late — money to pay, apologies to make, trust already lost. Set a stricter internal line (the SLO) first, and act at “nothing’s broken yet, but the signs are bad”. This discipline of “feel the pain yourself before the customer does” applies, I think, far beyond reliability — behind any external promise there should be a stricter internal demand cushioning it.

Good metrics pick “what users care about”, not “what’s easy to measure”

I’ve seen too many monitoring dashboards full of CPU, memory and QPS — good-looking, easy to collect, and not one of them answers “are users happy right now”. Defining SLIs forced me to switch seats: standing at the user’s end, what do they look at to judge whether the service is good? Almost always “did it succeed, was it fast, was it right, was it fresh”, never the resource numbers in my datacenter. The switch is basic, yet it’s the root cause of many teams monitoring for ages without hitting the point — you’re measuring your convenience, not their experience.

An SLO is a “deliberately written-down imperfection”

This post and the previous one together are really about one thing: first have a ruler everyone agrees on, and only then can everything else (error budget, release decisions, alerting) stand up. And the essence of that ruler is quantifying, stating and writing down the vague consensus of “how stable is enough”. Without an SLO the team talks past each other forever about “stable or not”, the error budget can’t be computed, and alerts don’t know whether to fire. Explicitly defining “good enough” sounds unremarkable, yet it’s the true starting point of reliability engineering — only a target that’s written down can be managed.