SRE in Practice: Setting Actionable SLIs, SLOs and Error Budgets

Choosing indicators that mean something

A good indicator measures what a user experiences. Availability of the checkout journey, latency of the search endpoint at the ninety-fifth percentile, and success rate of payment authorisation are meaningful. CPU utilisation and pod restart counts are diagnostic signals, not service level indicators.

Measure at the point closest to the user where you still control the result. Server-side measurement is usually preferable to synthetic probing because it reflects real traffic, provided that client-side and network effects are understood.

Start with two or three indicators per service. Availability and latency cover most needs, with a correctness or freshness indicator where data staleness matters, such as reporting or search indexing.

• Measure user journeys, not component health.
• Prefer server-side measurement of real traffic.
• Start with availability and latency, add freshness where it matters.
• Keep the indicator count small enough to be acted upon.

Objectives and error budgets

An objective sets the target for an indicator over a window, such as ninety-nine point nine percent of checkout requests succeeding over thirty days. A rolling window is usually better than a calendar month because it avoids a reset that hides chronic problems.

The error budget is what remains: at ninety-nine point nine percent over thirty days, roughly forty-three minutes of unavailability is permissible. That budget is the practical tool, because it gives a product and engineering team a shared quantity to spend on releases and migrations.

The policy attached to the budget is what makes it real. When the budget is exhausted, the default should be a freeze on reliability-affecting change until service is restored, with a documented exception path. Without a consequence, the budget is decoration.

SLAs versus SLOs

A service level agreement is a commercial instrument with financial or contractual consequences. An objective is an internal engineering target. The critical rule is that internal objectives must be stricter than the external commitment, because you need headroom to detect and correct a problem before it breaches a contract.

Expose objectives to customers selectively. Publishing current reliability builds trust, but publishing an internal objective as a commitment converts an engineering target into a liability.

Define the measurement method precisely in any agreement: what counts as a failure, how it is measured, what is excluded, and how the window is calculated. Ambiguity in the definition produces disputes during exactly the incident when nobody has time for them.

• Keep internal objectives stricter than external commitments.
• Publish reliability data without converting targets into commitments.
• Define failure, exclusion and window precisely in any agreement.
• Keep the number of formal agreements small.

Operating the practice

Dashboards should show the indicator, the objective, the remaining budget and the burn rate. Burn rate matters more than the current level, because a budget consumed in two days will exhaust long before the window ends even if today's number looks acceptable.

Alert on burn rate rather than on individual failures. A fast burn over a short window is a page; a slow burn is a ticket. This single change removes most alert noise while catching genuine degradation earlier.

Review objectives quarterly. As the system and its users change, an objective that was appropriate a year ago may be too loose to be useful or too tight to be achievable, and either way it stops influencing behaviour.

• Display burn rate alongside remaining budget.
• Page on fast burn, ticket on slow burn.
• Review and revise objectives quarterly.
• Tie post-incident review actions back to the indicators.