Set service-level objectives that change what the team works on

If a service misses its reliability target and the next sprint proceeds unchanged, the target may be a reporting metric rather than an operating objective. The service owner’s task is to connect user experience to a decision about engineering time: which work can proceed, which failure needs attention and who resolves a disagreement.

A service-level indicator, or SLI, is the measure. A service-level objective, or SLO, is the target for that measure over a defined period. A service-level agreement, or SLA, adds an agreement about the service and consequences of failing to meet it. An internal SLO should be chosen for the service’s users and operating needs, not copied automatically from a supplier’s contractual promise.

The useful starting point is a journey the business cares about. “Customers can complete checkout” is closer to a revenue consequence than “the application servers are running”. Server measures remain valuable for diagnosis, but they do not by themselves establish whether the journey succeeded.

Write the outcome before selecting the dashboard

Google’s SRE workbook distinguishes the intended service outcome from the implementation used to measure it. It recommends indicators expressed as good events divided by total events and discusses the blind spots of backend logs, synthetic probes and client instrumentation. This is a documented operating approach to adapt to your service, not a universal target to adopt.

For checkout, decide what completion means. Does it require an order to be durably accepted and a confirmation returned? How quickly must that happen? Which failures represent service unreliability, and which are genuine business outcomes such as an accurately reported payment decline? Make those distinctions with the product owner before a convenient HTTP status code becomes the definition.

Place the measurement boundary where the outcome can be observed. If the indicator starts only after a request reaches the backend, it cannot describe failures that prevent users reaching that backend. Retain an additional signal for that gap, such as an external journey check, and describe its coverage. No single reassuring percentage should hide an unmeasured part of the journey.

A checkout objective with visible arithmetic

Consider a hypothetical checkout service. Its team proposes that at least 99.9% of eligible checkout attempts should produce a durable accepted order and confirmation within two seconds, measured over a rolling 28-day window. The two-second threshold and 99.9% target are local assumptions for this example.

An eligible event is one submission with a valid checkout token from a real customer that reaches the defined checkout entry point. Deduplicate transport retries using the same attempt identifier. Exclude identified synthetic traffic and requests rejected as malformed before eligibility. Keep those counts separately visible. For this simplified example, no genuine business declines occur; a real design must define their treatment before measurement begins.

During the window, the entry-point counters record 505,000 events. There are 3,000 identified synthetic events and 2,000 malformed submissions outside the agreed eligibility boundary. That leaves 500,000 eligible attempts. Of these, 499,600 meet both the completion and time conditions; 400 do not.

The SLI is 499,600 ÷ 500,000 = 99.92%. At the 99.9% target, the allowed fraction of bad events is 0.1%, giving 500 bad events for this observed volume. The 400 observed bad events have consumed 80% of that budget, leaving 100 at this point in the window.

That remaining count is a snapshot, not a fixed allowance for the next day. In a rolling window, old events leave and new events enter, changing both the denominator and the number of bad events. It is also a request-based measure. It cannot be converted directly into minutes of permitted downtime without assumptions about traffic and the failures involved.

The combined success-and-latency definition prevents a completed but unusably slow checkout from being counted as good. Keep diagnostic measures for outright failures and slow successes separately, so the engineering team can see which problem is consuming the budget.

Decide the response before the argument begins

Google’s published example error-budget policy connects an exhausted budget to halting ordinary changes while allowing urgent issues and security fixes. It also describes escalation when teams disagree. The value for a service owner is the explicit link between evidence and action; the example is not a requirement to impose the same release rule everywhere.

For the checkout service, agree a policy with the engineering lead while the service is healthy. A fast deterioration should trigger investigation even if the 28-day target is still being met. Sustained budget exhaustion might pause discretionary changes that affect checkout while the team fixes the dominant failure mode. Security work and changes needed to restore service require an explicit route to proceed.

Give that policy a decision-maker. If commercial pressure favours a release while reliability evidence argues against it, somebody must accept the trade-off and record why. A target without authority behind it leaves the same negotiation to recur during every incident.

A dependency failure still affects the customer even when another team owns the component. Keep that impact in the journey measure. Responsibility for the repair can be assigned separately; removing inconvenient failures from the denominator would conceal the experience the SLO is intended to protect.

Start with a target the service can justify

Discuss the consequence of failed and slow checkouts, traffic patterns and the cost of further reliability work. Compare the proposed objective with observed performance and known measurement gaps. A stricter target should have a business rationale, not merely another nine in a presentation.

Review the first measurement period before using the objective to impose major delivery restrictions. Investigate missing events, duplicate attempts and questionable exclusions. Preserve a history of definition changes so an apparent improvement caused by a new denominator is not mistaken for a repaired service.

The SLO becomes useful when both product and engineering can explain what it measures and which decision it changes. From there, connect the relevant signals to alert ownership and response rules, so a deteriorating journey reaches someone able to act.