SLI / SLO / SLA

The three measurements every SRE conversation orbits — verbatim definitions, the differentiator test, and the canonical good/total form.

Overview

SLI, SLO and SLA

These three are the most-tested SRE definitions in interviews. Get them precise, because the differences are load-bearing.

The verbatim definitions

From the Google SRE Book Ch 4:

SLI (Service Level Indicator) — "a carefully defined quantitative measure of some aspect of the level of service that is provided."
SLO (Service Level Objective) — "a target value or range of values for a service level that is measured by an SLI."
SLA (Service Level Agreement) — "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain."

The differentiator test

> [!IMPORTANT] Ch 4, verbatim: "if there is no explicit consequence, then you are almost certainly looking at an SLO."

The canonical SLI shape

The Workbook (Ch 2) refines the SLI into a ratio of good events to total events: good_requests / total_valid_requests over a window.

Natural error budget — The budget is simply 1 − SLO
Aggregates cleanly — Ratios combine across windows and services
Resists averaging — Avoids the "fix the average, ignore the tail" failure mode

Key concepts

SLI — Service Level Indicator: The MEASUREMENT. "A carefully defined quantitative measure of some aspect of the level of service that is provided." (SRE Book Ch 4) — Always a number derived from observed events. Examples: % of HTTP requests returning 2xx; p99 latency in milliseconds; % of writes durable within 5 seconds. The SLI is what you actually measure on production traffic.
SLO — Service Level Objective: The INTERNAL TARGET. "A target value or range of values for a service level that is measured by an SLI." (SRE Book Ch 4) — A threshold you set on the SLI. Examples: "99.95% of HTTP requests return 2xx," "p99 latency under 500ms," "99.9% of writes durable within 5s." Owned by SRE + Dev + Product (three-way sign-off). When missed, the team has a meeting and decides what to fix — no automatic external consequence.
SLA — Service Level Agreement: The EXTERNAL CONTRACT with consequences. "An explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain." (SRE Book Ch 4) — Examples: "99.9% availability or customer gets 10% credit," "Tier-1 customers get $X penalty per minute beyond 4 hours of downtime." Owned by Legal + Sales + Product. Almost always LOOSER than the internal SLO (e.g., SLA = 99.9%, SLO = 99.95%) so engineering has headroom before refunds trigger.
Good / total form (canonical SLI shape): From Workbook Ch 2: SLI = good_events / valid_events over a window. The "valid" filter excludes things outside your responsibility (404s for nonexistent endpoints, requests rejected at the LB before reaching you). The "good" count is per the SLI definition (success+fast for latency SLI; just success for availability). Aggregates cleanly: SLI for last hour vs last day vs last 30 days are all the same shape. Yields a natural error budget (1 − SLO) measured in the same units.
The Differentiator test: Verbatim from SRE Book Ch 4: "An easy way to tell the difference between an SLO and an SLA is to ask 'what happens if the SLOs aren't met?': if there is no explicit consequence, then you are almost certainly looking at an SLO." — If the answer is "we have a meeting" → SLO. If the answer is "the customer gets refunded $X" or "we breach contract" → SLA. Most internal services have SLOs with no SLAs; SLAs are reserved for paid customer commitments.
SLI menu by service type: Workbook Ch 2 maps service types to recommended SLI categories. Request-driven services (HTTP, gRPC) → availability + latency + quality. Pipeline (batch, streaming) → freshness + correctness + coverage. Storage → durability + availability + latency. Most services need 2-4 SLIs covering different failure modes; one SLI is rarely sufficient. Avoid "comprehensive lists" — Workbook explicitly says fewer SLOs with better coverage beats many.

When to use it

Every reliability conversation starts here — get the three definitions right or the rest falls apart
Designing a new service's reliability targets — pick CUJ → SLI spec (good/total) → SLO threshold
Distinguishing internal targets (SLOs) from contractual obligations with refunds attached (SLAs)
Explaining to product why "always available" is not a measurable SLO

Interview questions

What's the difference between SLI, SLO and SLA — and what's the test that separates SLO from SLA?
Walk me through implementing an SLO for a brand-new web service.
Why measure with percentiles instead of averages?
I'm told to set the SLO at "100%" — what do I say?
Who owns the SLO — SRE, dev, or product?