SLA vs SLO vs SLI: What's the Difference?

The three terms get used interchangeably in standups, and they should not be, because they name three different layers of the same idea. The cleanest framing comes from the Google SRE book, which defines them as a stack that builds bottom-up. Start at the base with the SLI, the Service Level Indicator: a carefully defined quantitative measure of some aspect of the level of service. Request latency, error rate, throughput, availability — anything you can put a number on. An SLI is not a goal; it is just the ruler.

Set a threshold on that ruler and you get the middle layer, the SLO, or Service Level Objective: a target value or range for an SLI, measured over a window. 'The 30-day availability SLI should be at least 99.9%' is an SLO. It is the number your team commits to internally, and it is the pivot of the whole system — everything above it is a promise, everything below it is instrumentation. Put a contract around a set of SLOs, add money to the outcome, and you reach the top layer, the SLA or Service Level Agreement: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs it contains. The consequence is what distinguishes an SLA from an SLO. As the SRE book puts it, if there is no explicit consequence for missing the objective, you are almost certainly looking at an SLO, not an SLA.

Concreteness beats definitions, so take a single service and follow availability up the stack. The SLI is the measured proportion of successful requests: the count of valid HTTP responses divided by the count of total valid requests, sampled continuously. Over the last 30 days it reads 99.95%. That is a fact about the world, not a goal — just what the ruler currently says.

The SLO is the target you draw on that ruler: 99.9% of requests succeed over a rolling 30-day window. It is what your on-call rotation defends, what your alerts fire against, and what product signed off on. The SLA is the clause your customers actually see: we guarantee 99.5% monthly availability; fall below it and you receive a 10% service credit. Same underlying indicator — success rate — three different rows in the same table. Only the audience and the stakes change as you climb. And notice the deliberate gap: the 99.5% SLA sits below the 99.9% SLO on purpose, so that missing your internal goal is an early warning rather than an instant breach.

The reason to keep these straight is not pedantry — it is that the gap between the layers is where reliability engineering actually happens. First, you deliberately set your SLO stricter than your SLA. If the contract promises 99.5% and your internal objective is 99.9%, you have built yourself a buffer: your alerts fire on the tighter internal number, so incident response starts well before you are anywhere near owing a customer money. Breaching an SLO costs you a stressful week; breaching an SLA costs you credits and trust. The looser external promise is a feature, not sloppiness.

Second, the SLO is what generates your error budget — the amount of unreliability the objective permits. A 99.9% availability SLO grants a 0.1% budget: roughly 43 minutes of allowed unavailability per 30-day window. That budget is a currency. As the SRE book argues in Embracing Risk, it lets you spend reliability headroom on shipping speed: while the budget has room, push features and take risks; when it is nearly exhausted, freeze risky changes and prioritise stability. The error budget turns 'reliable vs. fast' from an argument into a number both engineering and product can read off the same dashboard. When incidents do eat the budget, tracking and shrinking your mean time to recovery is one of the highest-leverage ways to protect it.

A good SLI is user-centric and measurable. The SRE workbook recommends framing SLIs as the ratio of good events to valid events — proportion of requests served faster than a threshold, proportion returning a non-error status — because a normalised 0–100% figure is easy to reason about and to set a target on. The test for a candidate SLI is simple: if this number gets worse, does a real user feel it? Availability, latency, and correctness usually pass. CPU utilisation usually does not — nobody outside your team cares what your CPU is doing, only whether the page loaded. Measure the thing your user experiences, not the thing that is convenient to graph. Choosing the right signals here is really an observability problem: you can only set an SLI on behaviour your telemetry actually captures.

A realistic SLO is set by working backwards from what users actually need, then leaving deliberate headroom. Start loose, measure your current performance for a few weeks, and set the target where it keeps users happy without pinning you to perfection — you can always tighten it later. Resist the urge to promise nines you cannot defend, and resist the opposite urge to set a target so slack it never alerts. The SLO should be tight enough that breaching it means something is genuinely wrong and worth waking someone up for, which is also where your incident severity levels hook in: a sustained SLO burn is often what escalates an issue from a low-priority ticket to a paging Sev-1.

Put the whole stack together and the mental model is short enough to keep in your head. You measure with an SLI, you target that measurement with an SLO, and you promise a looser version of that target to customers with an SLA that carries consequences. The distance between the SLO and 100% is your error budget; the distance between the SLO and the SLA is your safety margin. Get the SLIs pointed at real user pain, set the SLOs just high enough to matter, and keep the SLA comfortably below the SLO — and the three acronyms stop being jargon and start being a control system for how much risk you can afford to ship.