SRE / Basic: promises and measurements / Lesson 4

Error budgets and release decisions

Translate an agreed reliability objective into a finite budget and a policy that changes engineering decisions when reliability deteriorates.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Compute allowed bad events and consumed budget.
Distinguish remaining budget from burn rate.
Design an exception-aware budget policy.

Understand the allowance

An error budget is the tolerated unreliability implied by an SLO. With a target of 99.9% good events, the allowed bad fraction is 0.001. For a completed window containing one million eligible events, that corresponds to one thousand bad events. This is an accounting allowance, not permission to harm a particular user or to violate a correctness obligation. The budget also depends on the chosen event population; increasing healthy traffic can change a request-weighted result without repairing failures experienced by a small group. Review important slices when aggregate success could hide disproportionate harm.

Calculate consumption explicitly

The offline calculation uses a fixed completed window so that the denominator is known. Three hundred bad events consume thirty percent of a one-thousand-event allowance, leaving seven hundred. In a live rolling window both eligible volume and old failures change, so remaining budget is not a fixed bank account. Label forecasts as forecasts and distinguish them from final accounting. Do not mix time-based downtime budgets with request-based budgets unless the definitions justify a conversion; a quiet hour and a busy hour can contain very different numbers of affected attempts.

python Offline fixed-window budget

eligible = 1_000_000
allowed_bad = eligible * 0.001
observed_bad = 300
print(f"allowed={allowed_bad:.0f}")
print(f"consumed={observed_bad / allowed_bad:.0%}")
print(f"remaining={allowed_bad - observed_bad:.0f}")

Expected output

allowed=1000
consumed=30%
remaining=700

The allowance is calculated from the agreed bad fraction. A negative remaining result would indicate an exhausted budget, not negative failures.

Separate speed from stock

Burn rate divides the observed bad fraction by the allowed bad fraction. At one-times burn, sustained behavior would consume the allowance over the full window under comparable event weighting. Ten-times burn is a warning about pace, even when much budget remains. Conversely a nearly exhausted budget can coexist with a currently healthy service because earlier failures still occupy the window. Use these two views for different decisions: recent burn informs urgent response, while remaining budget and trends inform planning. Any time-to-exhaustion estimate assumes future traffic and error behavior resemble the model.

Make the budget change decisions

A budget policy states what happens when evidence crosses agreed conditions. It might prioritize reliability work and pause nonessential risky changes after exhaustion, while permitting a reviewed security repair or an action needed to restore service. Name the decision owner and exception record. The illustrative agreement does not automatically disable deployments. Freezing every change without considering remediation can prolong an outage, while declaring every feature urgent makes the policy meaningless. Agree the policy while the service is healthy, when participants can examine tradeoffs without the pressure of an active incident.

yaml Editorial budget policy

condition: budget-exhausted
default: prioritize-reliability-and-pause-discretionary-risk
exceptions: [restore-service, reviewed-security-repair]
decision_owner: service-reliability-review
exception_record: reason-scope-evidence-and-expiry

The policy differentiates discretionary risk from remediation. It illustrates governance and has no deployment permissions or automation attached.

Review the incentives

Budget reporting should encourage learning and sensible risk, not concealment. If teams are penalized for reporting incidents, data quality will suffer. If third-party failures are automatically removed, the service objective may stop describing user experience. Record attribution separately from whether a user outcome was bad, and decide commercial exceptions through the proper process. Review whether the policy actually shifted engineering time toward the largest reliability risks. A useful budget can support feature delivery when service health is strong and protect capacity for repair when reliability weakens; it should not become a competitive score between unrelated teams.

Common errors and fixes

Budget is reset after each incident

Why it happens: The team treated an accounting window as a discretionary reset.
How to fix it: Retain the agreed window and document corrections.
Prevent it next time: Version definitions and audit exceptional adjustments.

A supplier outage is removed from user availability

Why it happens: Attribution was confused with user impact.
How to fix it: Keep user outcomes intact and label dependency attribution separately.
Prevent it next time: Review exclusions against the service promise.

A freeze blocks the recovery repair

Why it happens: The policy had no remediation exception.
How to fix it: Use a reviewed exception with an accountable owner.
Prevent it next time: Define exception scope before incidents occur.

Check your understanding

1. A 99.95% target has 400,000 eligible events and 100 bad events. Calculate the budget.

Show worked solution

The allowed bad fraction is 0.0005, giving 200 bad events. One hundred consumes 50%, leaving 100 in that completed-window calculation. The arithmetic does not establish how rapidly recent errors are occurring; inspect a recent interval to evaluate burn.

2. Should a planned feature always stop when budget is exhausted?