What an exhausted error budget changes

In a hypothetical release meeting, the service has used its failure allowance. The next package contains the repair and an unrelated feature. Pausing everything would block recovery; shipping everything would add risk the repair does not need. An error-budget policy gives people a way through that choice.

The policy says which changes continue, which pause and who may approve an exception as the allowance is consumed. Discuss the mixed package before an incident, while there is time to separate it or decide who can accept its extra exposure.

The request population determines the allowance

First define what customers should receive and how often they receive it. The measurement is a service-level indicator, or SLI; its target over a window is the service-level objective, or SLO. At 99.9% success, failed eligible requests may occupy 0.1% of the window’s count. That internal objective is not automatically a contractual service-level agreement, or SLA.

An argument after a freeze can begin with what was counted. If one team includes timed-out requests and another drops them because no final status arrived, they are measuring different promises. Define the eligible population, justified exclusions, sources and missing-data behavior before attaching release consequences. Otherwise the policy meeting begins again inside the incident.

Keep SLI changes reviewable for the same reason. Measurement defects should be corrected, but silently redefining a bad event during an incident would make the chart greener without explaining what happened to users. Retain the old and new interpretations so the release decision can be understood afterward.

For a simple request-based example, one million eligible requests at a 99.9% success objective allow 1,000 bad requests over that window. If 1,200 are observed, the allowance is exceeded by 200. That arithmetic describes the service result; it does not identify whether the next artifact is a risky feature or the repair needed to recover. The policy supplies that next distinction.

How consumption affects planned work

Translate “prioritize reliability” into the calendar. A discretionary release waits, a recurring failure receives engineering time, or expansion needs another review. Pair the observed condition with the specific decision and the person able to carry it out.

Remaining budget and burn rate answer related questions: how much allowance is left, and how quickly it is being consumed. Rapid consumption can warrant action before exhaustion. Google's burn-rate alerting chapter explains that relationship and why low-traffic signals need careful interpretation.

The proposed change matters as much as the current balance. A repair may reduce ongoing harm while an ordinary feature introduces additional exposure. A dependency-caused breach also needs a response, even if the service team did not cause it. Attribution belongs in the review, but the immediate decision concerns the experience users are currently getting.

Connect budget consumption to a usable policy

Read diagram description

Illustrative policy flow. The SLO defines the allowance; the organization decides what consumption changes. An urgent exception still needs an authorized decision and an expiry. Diagram labels: SLO measurement: Eligible events, target and window; Budget consumption: Remaining allowance and burn rate; Agreed policy: Continue, pause or consider a scoped exception; Release decision: Named decision maker, checks and review point.

A repair bundled with an unrelated feature

Consider a hypothetical exhausted budget and a release that bundles a reliability fix with an unrelated feature. Separating the artifact would let the team consider the repair on its own. If that is not feasible, someone with the necessary authority must explicitly decide whether the expected recovery benefit justifies the additional feature's exposure.

Record the actual package, current customer impact, expected benefit, approver and outcome checks. Give the exception an expiry and bind it to this situation. Calling everything urgent would leave the unrelated feature’s risk unexamined.

Leadership accepts risk within its authority; technical owners establish whether execution is feasible and recoverable. An incident lead coordinates the response but does not automatically acquire every approval power. Giving these roles a defined escalation route spares the on-call responder from inventing the division while also trying to restore service.

The same policy should explain who acts when a dependency consumed the budget and the team cannot repair it directly. Depending on the service, the work may involve fallback behavior, demand limits or a changed commitment with the provider. Leaving that case unassigned turns cross-service failure into a debate about fault while customer impact continues.

Different services can need different policies. Consistent measurement and explicit exceptions matter more than imposing one release freeze on every workload regardless of user impact.

What held releases and exceptions reveal

Examine held releases, granted exceptions, repeated exhaustion and customer failures the SLI missed. A gate may enforce the written rule perfectly while blocking harmless work and admitting the recurring failure mechanism. Those outcomes are evidence for revising the agreement rather than celebrating consistent enforcement.

The error-budget policy template records the agreement, the release-gate guide covers implementation and the error-budget calculation reference keeps the arithmetic explicit. Using them together should make it possible to reconstruct why a release proceeded or stopped without relying on someone's memory of the incident.

The mixed package becomes easier to handle when delivery and recovery owners have already worked out a repair-only path or an explicit exception. The failure count can then guide a decision instead of starting a new argument about what the count means.