Choosing the Right SLI

The SRE Workbook's SLI taxonomy and how to pick which to measure for which service.

Overview

The most consequential observability decision

A bad SLI makes a service look healthy while users are unhappy; a good SLI fires when users feel pain. The SRE Workbook (Ch 2) names six SLI types, each for a different kind of work.

The six SLI types

1. Availability — "% of valid requests served successfully" — Request/response services — good = HTTP 2xx (or 4xx attributable to the client). bad = HTTP 5xx. 99.9% of HTTP requests return success
2. Latency — "% of valid requests served faster than threshold" — Services where speed matters — good = duration [!TIP] Pick the latency threshold from user expectations, not engineering convenience.

The unifying formula

Exclude what genuinely isn't yours, such as requests for nonexistent endpoints.

> [!WARNING] Don't exclude 5xx by classifying them as "client error." That is gaming the SLI.

How to pick

HTTP service — Availability + latency
Batch pipeline — Freshness + coverage
Streaming consumer — Freshness (lag) + throughput
Best-effort cache — Availability with quality (degraded responses count)
Database — Availability + latency, sometimes durability (probabilistic)

> [!IMPORTANT] The Workbook's rule: start with the user's journey. What does success look like to them? Translate that into events; the SLI is the fraction that succeed.

Key concepts

Availability SLI: good = success / valid. For request/response services. The default.
Latency SLI: % of requests under threshold. Often two thresholds: typical-fast and acceptable-slow.
Quality SLI: % of requests served at full (non-degraded) quality. For services with graceful degradation.
Freshness SLI: % of data updated within window. For pipelines, replication, batch jobs.
Coverage SLI: % of input data that completed processing. For pipelines that can drop records.
Throughput SLI: % of time minimum throughput is met. For streaming systems.

When to use it

Defining a new service's SLO — pick the SLI types first
Auditing an existing SLO — does it actually track user experience, or is it a vanity metric?
Reviewing batch pipelines — availability is wrong here, freshness/coverage are right
Designing degraded-response paths — quality SLI captures partial-failure correctly

Interview questions

How do you choose an SLI for a service?
For a Kafka consumer, what SLIs do you use?
What's the difference between latency and quality SLIs?