“The system must be available” does not tell us what a user experiences or when a team should change priorities. An SLI, an SLO and an error budget turn a broad reliability goal into a measurement and a decision. Start with an important user action; choose the percentage afterwards.

Three terms with different jobs

  • SLI (service level indicator) measures the proportion of good events among the events we agreed to count. It might track orders completed successfully within an agreed time.
  • SLO (service level objective) sets a target for that SLI in a defined window, such as 99.9% over a rolling four weeks.
  • Error budget is the number or share of events that may fail the objective during that window. An SLA is a separate commitment to a customer, often with contractual consequences.
Fictional example: a system receives 1,000,000 eligible checkout attempts over four weeks. A 99.9% SLO leaves 0.1%, or 1,000 unsuccessful attempts, in the budget. If 700 attempts fail the defined condition, 300 remain. This illustrates the arithmetic; it does not recommend one SLO for every system.

What exactly counts?

In this example, a “good” event could be an order confirmation returned within an agreed two seconds of a valid request. Specify where you measure, which attempts qualify, and how you treat user cancellations, retries, invalid input and missing telemetry. Without an explicit denominator, you can improve a chart by excluding difficult cases while the customer experience stays the same.

A measurement at the boundary of the user journey can be more useful than the availability of individual services. Payment and inventory APIs might each look healthy while too many checkouts fail end to end. CPU and pod counts help diagnose a problem, but cannot stand in for the user outcome.

How does the budget inform a decision?

  1. Agree on the critical journey, SLI definition, realistic target and measurement window with the product owner. Review historical data and instrumentation quality.
  2. Write down a response policy with the team: who investigates rapid budget consumption, when risky releases are slowed, and when resilience work gets priority. No single threshold is a universal policy.
  3. After an incident, separate cause from effect. Check whether a slow dependency, retries, shared capacity or faulty measurement actually accounts for lost “good” events. Choose an architecture change only after that investigation.
Illustrative ADR excerpt: Context: release decisions rely on individual API availability while users report incomplete checkouts. Decision: measure the share of eligible checkouts confirmed within an agreed time; set the target and response threshold with product after reviewing data. Alternative declined: API availability alone misses the outcome of the full journey. Consequence: we need a consistent attempt ID, latency data and a review of measurement quality. Verification: slow a dependency in a test and check whether the SLI reflects lost confirmations.

Project question: can you name one critical user action, count its failures from trustworthy data and explain which decision would change if the budget burned quickly?

Sources and scope: the definitions and SLO approach follow Google SRE — Service Level Objectives and Google SRE Workbook — Implementing SLOs. The 99.9% example with one million requests in four weeks is also shown in Example Error Budget Policy. The checkout scenario, ADR, two-second condition and proposed steps are original illustrations, not a report of a real deployment.