An error budget is only useful if it changes a decision. Here is how we turned burn rate into a number product and engineering both act on.

Error budgets are supposed to end the fight between shipping fast and staying up. In practice they start a new one: whose burn was it, and who has to slow down.

Attribute burn before you argue about it

The fastest way to make an error budget political is to argue about attribution during an incident. We now tag every deploy with a change marker and join it against the burn-rate query automatically, so "was this the release?" is answered before the retro starts, not during it.

from slo_burn("checkout-api")
| join kind=leftouter (deploys | where service == "checkout-api") on $left._time between (deploy_time .. deploy_time + 30m)
| where burn_rate > 2
| project _time, burn_rate, deploy_id, deploy_owner

Write the policy before you need it

The policy — what happens at 25%, 50%, 100% of budget consumed in a window — has to exist before the first freeze, or it gets negotiated live under pressure, which always favors whoever is loudest in the room. Ours is three lines: 50% consumed triggers a review in the next reliability meeting, 100% consumed in a rolling 7-day window triggers a feature freeze on that service until burn rate drops below 1x for 48 hours.

The freeze is scoped to the service, not the org. That single change removed most of the political resistance — nobody has to defend freezing checkout to ship an unrelated billing feature.

Make the budget visible where decisions happen

We stopped putting burn rate in a dashboard nobody opens and started putting it in the sprint planning doc as a single line, refreshed automatically. Engineering managers now see "checkout-api: 38% of monthly budget consumed" next to the backlog, which turns an abstract reliability goal into a number that competes with feature requests on the same page.

Separate the budget conversation from the blame conversation

The fastest way to make engineers hide burn-rate data is to let budget reviews turn into a hunt for who to blame for the consumption. We explicitly frame the sprint-planning line as a capacity signal, not a scorecard — the question on the table is always "what do we do about this now," never "whose fault was this deploy," and that framing is stated out loud at the start of every review that touches a budget number.

  • Join burn-rate spikes against deploy markers automatically — don't argue attribution live.
  • Write the freeze policy before the first freeze, scoped per service.
  • Surface budget consumption next to the backlog, not in a separate dashboard.
  • Frame budget reviews around action, not blame — say so explicitly.
  • Review budgets on a fixed cadence, not only when something breaks.