A team consistently exhausts its error budget and continues shipping features. What has gone wrong, and what would make the budget actually function?

What has gone wrong

The budget has no consequence, so it is a metric rather than a control. An error budget only works if exhausting it changes what the team is allowed to do, and that change has to be agreed in advance by whoever would otherwise override it.

The second common cause: the SLO was set at a level nobody actually intended to meet, usually copied from another team or chosen because the number looked respectable. A budget derived from an aspirational target is exhausted permanently, so it carries no information and gets ignored — correctly.

What makes it function

• A pre-agreed consequence, written down and signed off by engineering and product together, before it is needed. Typically: feature work stops, reliability work takes priority, and the freeze lifts when the trailing-window budget recovers.
• An SLO derived from what users actually need, not from what sounds good. If the business is content with 99.5% for a given journey, setting 99.99% creates a permanently exhausted budget and destroys the mechanism.
• A trailing window, so the budget recovers gradually rather than resetting on the first of the month and encouraging a spend-it-early pattern.
• An explicit override path with a named approver and a record. Overrides will happen; the question is whether they are visible. An unrecorded override is indistinguishable from the budget not existing.
• Budget consumption visible continuously, not discovered at a monthly review, so the team can act before it is exhausted.

The deeper condition

The budget must be owned by someone who is also accountable for delivery. If reliability is owned by an operations team and delivery by a product team, the budget is a constraint imposed by one group on another and it will be argued away every time.

When the same person is accountable for both, the budget becomes what it was designed to be: a mechanism for making an unavoidable trade-off explicit and consistent, rather than re-litigating the reliability-versus-speed argument in every planning meeting.

The failure to avoid on the other side

A budget used punitively produces incident under-reporting and SLI gaming — measuring the metric that looks best rather than the one that reflects the user. The budget is a signal for prioritisation, not a performance review, and the moment it becomes the latter it stops being accurate.