Service Level Indicator

Origin & evolution

The term was given its working definition by Google's Site Reliability Engineering practice, set out in the SRE book (2016). The book defines a service level indicator as "a carefully defined quantitative measure of some aspect of the level of service that is provided." It sits in a trio: the indicator is what you measure, the objective🏁ObjectiveStrategyA strategic goal (OKR)View reference → is the target you hold it to, and the agreement is the contract with consequences.

The SRE Workbook (2018) sharpened the recommended form into a ratio: good events divided by valid events, multiplied by a hundred for a percentage. The phrasing repays attention. "Valid events" is not "all events." A well-built availability indicator excludes events that say nothing about service health, so client errors in the 4xx range and redirect responses are often kept out of the denominator. Folding them in punishes the service for a user mistyping a URL, which corrupts the signal.

The standing debate is which indicator to pick. The SRE guidance is to choose few, and to choose those that track the user's actual experience. A service can post 99.99% on a CPU graph while every user request times out. The indicator has to measure something a user would notice, and ideally something they would complain about when it slips.

How it works in practice

An API team picks availability as its first indicator. The naive version, "successful responses over all responses," counts a flood of 401s from an expired token integration as service failures, dragging the number down for a problem the service did not cause. They redefine it: good events are responses with a 2xx or 3xx status, valid events exclude 4xx client errors, and the indicator is the ratio of the two over a rolling 28-day window.

Now the number means something. When a deploy starts returning 500s, the indicator drops within minutes, and because the denominator is clean, the drop reflects a real regression the team owns. They add a second indicator for latency, the share of requests served under 300 milliseconds, because availability alone would call a slow-but-answering service healthy. Two well-chosen indicators describe the experience; ten poorly chosen ones describe noise.

Service level indicator vs. its neighbours

• Service level objective🥅Service Level ObjectiveDevOps & PlatformA service level objective (SLO)View reference →: the objective is the target the indicator must meet, such as 99.9% over a quarter. The indicator is the live measurement; the objective is the line drawn across it. You cannot set an objective until you have an indicator to set it on.
• Error budget⏳Error BudgetDevOps & PlatformAn error budget for a serviceView reference →: the budget is what remains once the objective is met, the allowed quantity of failure. It is computed from the indicator and the objective together. The indicator measures reality; the budget measures how much reality may diverge from the target before action is forced.
• Metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →: a metric is any raw measurement a system emits, CPU load, queue depth, request count. An indicator is a metric (or ratio of metrics) deliberately chosen because it reflects the user's experience. Most metrics are not indicators, and treating them as such is how dashboards🎛️DashboardData & AnalyticsAn analytics dashboardView reference → turn green while users suffer.

In the graph

In the Unified Product Graph, a service level indicator sits in the operations region as the empirical floor of a reliability target. Its defining relationship is upward: an objective is measured by an indicator (service_level_objective_measured_by_service_level_indicatorService Level Objectivemeasured byService Level Indicatorhierarchy). That single edge carries weight, because it forces every objective to name the concrete quantity it rests on. An objective with no indicator is an aspiration; an indicator with no objective is an ungoverned number on a chart. The graph insists the two travel together, which is the discipline that makes a reliability programme more than a wall of dials.