SLI, SLO, SLA — From Metric to Objective to Contract

SLI, SLO, and SLA differ by one letter and get lumped together, but they live on different layers. In one line: an SLI is a measurement, an SLO is an internal objective, an SLA is an external contract. The previous post said SRE starts by quantifying reliability — that quantification is exactly these three layers. This post works through them not as definitions but in the order you’d actually set them for your own service.

SLI — what to measure #

An SLI (Service Level Indicator) is a measurement of service level. The crux: measure what users experience. CPU utilization isn’t an SLI — users don’t feel it (it’s an operational metric). What users feel is whether their request succeeded and how fast it was.

In practice, SLIs are mostly defined as ratios: good events ÷ total events.

• Availability SLI: non-5xx responses ÷ all requests
• Latency SLI: requests answered within 300ms ÷ all requests
• Quality/correctness SLI: jobs processed without error ÷ all jobs (batch, pipelines)

The trick is defining latency not as “average response time” but as “the share of requests under a threshold.” Averages let the many fast requests mask the few slow experiences; the ratio form directly states “what percentage of users had a good experience.” Decide the measurement point too — server logs, load balancer, or real clients give different SLIs for the same service. Prefer the point closest to the user (load balancer or beyond) when you can.

Two or three SLIs are enough. Declare ten and nothing is really an objective.

SLO — what level to promise (internally) #

An SLO (Service Level Objective) is an SLI with a target attached: indicator + target + window, as in “availability SLI ≥ 99.9% over 30 days.”

The realistic way to pick the number is bottom-up, not top-down.

1. Measure current performance first. The last month or two of the SLI is your de facto current level.
2. Find the floor users and the business require. How many minutes down per month actually causes damage?
3. Start with an attainable value between the two. Open with an aggressive target and you begin in violation from month one — the practice is dead on arrival.

Here you need a feel for the nines. Converted to allowable downtime, the weight of each target becomes visible.

Each added nine multiplies cost roughly by an order of magnitude. And 100% cannot be the target: users can’t even distinguish reliability above the floor set by their own connectivity. The failure share you deliberately leave on the table becomes the next post’s error budget.

SLA — an external contract with penalties #

An SLA (Service Level Agreement) is a contract with customers. Miss the level and compensation follows — credits, refunds — making it a legal document whose numbers are set by business and legal, not engineering.

One working rule: the SLA sits looser than the SLO. Internal objective 99.95%, external contract 99.9% — the layering means an SLO violation isn’t automatically a compensation event, and you get a buffer to respond. Selling your SLO as your SLA turns the target into a contract with no cushion. Cloud providers’ SLAs (the compensation-backed 99.9%-ish numbers) sitting below their internal targets is the same structure.

Read SLAs in reverse, too: an external service’s SLA means “below this, they pay you back,” not “this level is guaranteed.” If a dependency’s SLA is lower than your SLO, your SLO is already at risk from that dependency alone — and serial dependencies multiply: two 99.9% components in series give 99.8%.

The three layers on one line #

Filling in the layers for an order API:

• SLI: non-5xx response ratio (availability), within-500ms ratio (latency) — measured at the load balancer
• SLO: availability 99.9%, latency 99%, over 30 days (internal target; what dashboards and alerts key on)
• SLA: below 99.5% monthly availability, credits are issued (customer contract; business decides)

Three common mistakes to note: using metrics users don’t feel (CPU, node counts) as SLIs; declaring SLO numbers with no measurements behind them; and setting SLA equal to SLO.

Summary #

• SLI is the measurement, SLO the internal objective, SLA the compensation-backed external contract — different layers.
• Define SLIs as good-event ratios of what users feel, and keep them to two or three. Latency too: threshold ratio, not average.
• Start SLOs between measured reality and the business floor. Every extra nine costs an order of magnitude.
• Keep the SLA looser than the SLO for buffer, and account for dependency SLAs multiplying down your target.
• 100% is not a goal. Spending the deliberately reserved failure share is the next post: the error budget.