A service exhausts its error budget in week two of a 28-day window. What actually happens next?

What is being tested

Whether you understand that the error budget's value is the pre-agreed consequence, and whether you can describe what that consequence actually is.

What should happen

Feature work stops; reliability work starts. That is the agreement, and the point of making it in advance is that it does not have to be negotiated during the period when everyone is most inclined to negotiate it.

Concretely:

• Risky deployments pause. Ship only reliability fixes and changes that reduce risk.
• The team's next-sprint priorities become the top contributors to the budget burn, identified from incident data.
• Someone senior enough to enforce it is informed, and the pause is visible rather than quiet.

Before enforcing, verify the budget was genuinely spent

Two checks that regularly change the answer:

Is the SLI measuring the right thing? A budget burned by synthetic probe failures, a monitoring outage, or a client with a broken retry loop hammering an endpoint is not a real reliability problem. Fix the measurement, do not stop the roadmap.

Was it one event or a pattern? A single 40-minute incident that consumed the whole budget is a different problem from a steady erosion. The first needs that incident's causes addressed; the second means the service is structurally at its reliability limit and needs architectural work rather than a fix.

Why the policy is what makes the SLO real

Without a consequence, "we should be more reliable" competes with "we should ship faster" every sprint and loses differently each time depending on who is in the room. With a budget, the trade is decided in advance and enforced by data rather than by seniority.

This is the part most often lost when the practice is adopted. The framing comes from Google's site reliability engineering, and an error budget adopted as a metric without the product organisation genuinely agreeing to the consequence becomes another dashboard nobody acts on — after which the practice is blamed for not working.

The symmetric half, which is under-used

A team with budget remaining should be moving faster. Consistently finishing a window with 90% of the budget unspent is evidence of over-investment in reliability at the expense of delivery. The correct response is to take more risk: deploy more often, reduce staging ceremony, spend the budget.

100% reliability is not the goal, and treating unspent budget as success misses half the mechanism.

What a strong answer adds

If the budget is exhausted every window, the SLO is wrong — either set by aspiration rather than by what the architecture can deliver, or the architecture needs investment nobody funded. A permanently breached SLO is a permanently ignored one, and it is worse than having none because it trains people to disregard the whole framework.