An error budget policy written during calm times gets renegotiated the moment a big launch is on the line. Here is how we made ours hold.

Every error budget policy sounds reasonable in a planning doc. The real test is whether it survives the week before a launch the whole company is counting on.

Write exceptions in, not around

Our first policy had no exception process, so the first time a launch conflicted with a budget freeze, the team simply ignored the policy and shipped anyway — which taught everyone the policy was optional. The rewrite includes an explicit exception path: a VP can approve a time-boxed, logged override, capped at 14 days, after which the freeze re-applies automatically whether or not anyone remembers to lift it.

Automate the trigger, not the decision

The freeze condition itself is computed automatically from burn rate, not decided in a meeting — that removes the moment where someone can argue the numbers don't really mean what they say.

from slo_burn("checkout-api")
| summarize consumed = max(cumulative_burn_pct) over(last 7d)
| extend freeze_active = consumed >= 100
| where freeze_active == true

Make the cost of overriding visible

Every override is logged with who approved it, why, and for how long, and that log is reviewed publicly in the monthly reliability review. Visibility, not enforcement, turned out to be what discouraged casual overrides — nobody wants their name on a list of budget exceptions justified by "the roadmap deadline was already announced."

Involve product in writing it, not just engineering

Our first draft was written entirely by the SRE team and read, to product stakeholders, like an obstacle rather than a shared agreement — which is exactly why it got quietly bypassed the first time it was inconvenient. The rewrite had a product leader co-sign the exception thresholds, and having someone with launch-timeline authority already bought into the policy meant the override conversation during our next big launch took ten minutes instead of a day of escalation.

  • Build an explicit, time-boxed exception path instead of hoping nobody needs one.
  • Compute the freeze trigger automatically from burn rate, not by discussion.
  • Cap overrides and auto-re-apply the freeze when the cap expires.
  • Log every override publicly and review it in the monthly reliability meeting.
  • Co-author the policy with product, not just engineering, so it isn't seen as an obstacle.