SLI (Service Level Indicator)

A service level indicator (SLI) is the measurement that tells you how well a service is actually performing. Google’s Site Reliability Engineering book defines it as a carefully defined quantitative measure of some aspect of the level of service that is provided. The word that matters is carefully: most arguments about whether a service met its target turn out to be arguments about what the indicator meant.

SLI, SLO, and SLA

An SLI defines a measurement; an SLO sets its target; an SLA includes the agreed consequences of meeting or missing a service commitment. They can use common event definitions while applying different windows or exclusions. In this illustrative checkout example, all three use the same population, boundary, and calendar month:

• SLI: the fraction of eligible checkout requests that return successfully within two seconds, measured at the load balancer over the calendar month.
• SLO: that fraction stays at or above 99 percent.
• SLA: if that same monthly fraction falls below 98 percent, the provider issues the agreed service credit.

The indicator’s definition and its observed value are distinct: a reading of 99.2 percent describes the result for a month under the stated rule. If the internal SLO instead uses a rolling 28-day window, calculate that result separately rather than applying the calendar-month reading to both commitments.

State it as good events over valid events

The Site Reliability Workbook recommends a ratio of good events to valid events as a useful SLI form. It supports error-budget arithmetic and common alerting tools. When the denominator is nonzero, 100 percent means all included events met that particular rule, not that every aspect of the service was healthy. With no eligible events, define a no-data policy rather than silently reporting success. Other indicators, including throughput and latency distributions, remain useful when they match the service promise.

The ratio form also forces the two decisions that are otherwise left vague. What makes an event good — a success response, within a latency threshold, with correct content? And what makes it valid — are health checks, client-canceled requests, or requests rejected for malformed input counted in the denominator? The same discipline a quality requirement needs before the system exists: population, boundary, window, pass rule. This is also the fix for latency averages. Instead of average response latency, which hides the slow tail, define a good request as one completing under a threshold and measure the fraction that do. The SRE book’s broader advice is to treat metrics as distributions rather than averages — reported as a percentile when the question is how bad the tail is rather than how many requests cleared the bar.

Specification and implementation

The workbook separates what an indicator means from how it is measured. The SLI specification is the outcome that matters to users, independent of measurement — the home page loads in under 100 milliseconds. The SLI implementation is that specification plus a way to measure it. The same specification can be implemented in several ways, and each sees a different slice of reality:

• Application server logs are direct, and often the cheapest option where the logs already exist, but miss requests that fail before reaching the server.
• Load balancer monitoring catches more of the failures users see.
• Black-box probers detect network-level problems, but only for the paths they exercise.
• Client-side instrumentation can measure the user-facing boundary directly. Implementation and collection costs depend on existing instrumentation, client coverage, sampling, and the telemetry pipeline.

The SRE book adds that some systems need client-side collection precisely because server-side metrics can miss problems that affect users. Whichever you choose, write down the details that make two people compute the same number: the aggregation interval, the aggregation region, how often measurements are taken, which requests are included, how the data is acquired, and how stale the data may be when read.

What to measure depends on the system

The SRE book groups the usual concerns by system type:

• User-facing serving systems: availability, latency, and throughput.
• Storage systems: latency, availability, and durability.
• Big data systems: throughput and end-to-end latency.
• All systems: correctness — whether the right answer was returned, the right data retrieved, the right analysis done.

For a data pipeline, end-to-end latency usually shows up as freshness: the fraction of hours in which a table was no more than two hours behind its source. Demand belongs in the statement too — an indicator measured at one request rate does not guarantee the same result at another. A query returning the wrong total can pass latency or availability indicators whose success rules do not test content. Correctness can be included in a good-event rule or measured separately through a reconciliation against the source or on data quality checks. State what those checks establish and what the serving-path measurement omits.

What is not an SLI

A metric should be judged by the service promise it measures. Mean time between failures describes intervals between failures; it does not by itself tell users how long outages last or what fraction of their requests fail. Supply-chain measures such as on-time delivery can support objectives for those services, although they are outside this entry’s software examples. State the population, measurement boundary, and target before deciding whether a metric is an appropriate SLI.

References

• Google, Site Reliability Engineering, Service Level Objectives
• Google, The Site Reliability Workbook, Implementing SLOs