Service Level Indicator (SLI)

Definition

A Service Level Indicator (SLI) is a carefully-chosen quantitative measure of a service's behaviour, framed from the perspective of the user. It is the raw number that a Service Level Objective (SLO) is set against, and against which an error budget is consumed. The Google SRE canon defines an SLI as "the ratio of good events to valid events" — a formulation that has quietly become the industry standard.

Common SLI Categories

• Availability — fraction of successful requests over total valid requests.
• Latency — proportion of requests faster than a stated threshold (e.g., 95% of requests under 200 ms).
• Throughput — requests per second sustained without degradation.
• Correctness — proportion of responses that produce the correct result (relevant for search, ML, computation).
• Freshness — for data services, the age of the most recent successful update.
• Durability — fraction of committed data still recoverable after N days/years.

Why It Matters

Reliability discussions without SLIs collapse into anecdote. Engineering leaders say "the service is slow"; product owners say "customers are complaining"; support says "tickets are up 30%." An SLI turns those statements into "the 95th-percentile latency for the checkout endpoint has moved from 180 ms to 340 ms over the last two weeks." That is a number you can defend, argue against, or act on. SLIs are the vocabulary of honest reliability engineering.

Real-World Example

A ride-hailing platform ran a monthly reliability review dominated by dashboard theatre — 47 charts, colour-coded, argued over for an hour, no decisions made. The SRE lead proposed replacing them with three SLIs per critical service, each expressed as "good requests over valid requests" over a rolling 28-day window. Checkout: 99.87% success (SLO 99.9%, budget consumed 130%). Fare calculation: 99.94% (SLO 99.9%, budget consumed 60%). Driver dispatch p95 latency: 3.1s (SLO under 3.0s, budget consumed 145%). The review took 15 minutes. Two services with consumed budgets triggered feature-freeze until reliability work was completed. Six months later the pattern of missed budgets had inverted — teams shipped less feature work in the short term and were shipping considerably more of it reliably in the medium term.

Practical Lessons Learned

• Pick from the user's perspective. An SLI that measures internal server CPU is not an SLI; it is a metric.
• Fewer is better. Three well-chosen SLIs per service beats twenty half-defined ones.
• Ratios beat absolutes. "99.9% of requests succeeded" is comparable across scales; "we had four errors last hour" is not.
• Define "valid" carefully. Requests from health checks, warmup traffic and known bots usually should not count as valid events.
• Measure at the boundary the user experiences. Client-side or edge measurement often reveals problems that server-side metrics miss.

Common Mistakes

• Confusing SLIs with metrics — an SLI is a chosen, user-facing measure; a metric is anything you can plot.
• Averages instead of percentiles for latency — a 200 ms average hides the 10-second tail that everybody notices.
• Windowing choice that hides events — a rolling 24-hour window smooths out a five-minute incident that nevertheless mattered.
• Health-check traffic left in the SLI numerator, inflating success rates.
• SLIs defined by the platform team without input from the product team, so they measure the wrong user journey.
• Too many SLIs. A team with 40 SLIs has no SLIs — nothing gets prioritised.
• No linkage between SLIs and error budgets, so measured breaches trigger no action.

Expert Tips

• Write the SLI in one sentence. "Proportion of checkout POST requests returning 2xx within 500 ms over a rolling 28-day window, excluding health checks and warmup traffic." If it takes a paragraph, it isn't ready.
• Use percentiles that match user pain. p50 tells you about the median user; p95 tells you about the loud user; p99 tells you about the churning user.
• Publish the SLI query publicly — the exact Prometheus/CloudWatch/Datadog query — so anyone can reproduce the number.
• Review SLIs quarterly. User journeys change; measures should evolve with them.
• Pair every SLI with an SLO and a linked action — otherwise it is just a chart nobody reads.

Key Takeaways

• An SLI is a chosen, user-facing, quantitative measure — not just any metric you can plot.
• Ratios beat absolutes; percentiles beat averages.
• Three or four SLIs per service is enough; more dilutes attention.
• Define "valid" carefully — health checks and warmup traffic usually don't count.
• An SLI without a linked SLO and action is a decoration, not a control.

Related Concepts

Interlocks with SLOs, Error Budgets, Observability, Incident Management, and Blameless Post-Mortems. SLI catalogues and query templates at PMMilestone.org.