Error Budget

An SLO states a target: 99.9% of requests succeed over a rolling window. The error budget is the complement — the 0.1% that may fail without breaching the objective. Over 28 days that is roughly 40 minutes of complete unavailability, or a considerably longer period of partial degradation.

Its function is not to measure reliability, which the SLO already does. Its function is to make a recurring prioritisation argument answerable with data, by attaching an automatic consequence to a number everyone has already agreed on.

Why it matters

"Should we ship features or improve reliability?" has no answer in the abstract and is therefore settled by organisational politics — whoever argues most persistently, or whoever was most recently paged. "Have we spent our error budget?" has an answer, and it determines the priority without a debate.

The symmetry is the part most often missed. Budget remaining means ship, and take risks — the budget exists to be spent. It protects velocity as firmly as it protects reliability, and a team using it only as a brake has adopted half a mechanism.

Implementation patterns

• SLOs set from what users actually need, derived from journeys and business impact — not from a number chosen for its appearance.
• Measured at the point of user experience: client-observed success, or at minimum a measurement that includes timeouts and errors beyond the load balancer.
• Per user journey, not per service. Service-level budgets can all be green while the journey crossing five of them fails, which is the most common instrumentation error in this area.
• A rolling window rather than a calendar month, so the budget does not reset conveniently after a bad week.
• A written policy agreed in advance, specifying what happens at exhaustion, signed by the people who will resent it.
• An explicit, time-boxed exception process with a named approver, because a policy with no exception process is broken around rather than followed — and a visible exception is far better than an invisible one.
• Burn-rate alerting: alert on the rate of consumption, not only on exhaustion, so a fast burn is caught in hours rather than at the end of the window.
• Reviewing the shape of consumption, since one large incident and steady erosion have entirely different remedies.

Industry example

The practice originates in Google's SRE model, where the error budget is the formal interface between the teams building features and the teams operating systems, and where budget exhaustion carries a defined consequence — typically a pause on feature releases to that service until the budget recovers.

The published accounts are consistent that the mechanism's value comes from the consequence being agreed beforehand and honoured afterwards. Organisations that adopt the measurement without the consequence get a dashboard; organisations that override the consequence whenever it binds get a dashboard within two quarters.

Failure scenarios

• An SLO set too high, so the budget is permanently exhausted and the policy is ignored within a month.
• An SLO set too low, so it never binds and changes nothing.
• Measurement that misses user experience, keeping the budget green through a bad outage.
• No agreed consequence, reducing it to a reporting artefact.
• Repeated overrides, which teach the organisation that the policy is advisory and end the mechanism permanently.
• Per-service budgets hiding a broken cross-service journey.
• No ownership, so exhaustion is nobody's responsibility.
• A consistently unspent budget treated as success rather than as evidence of over-investment.

Trade-offs

Error budgets impose a rigid consequence on a nuanced situation. A budget exhausted by a single unusual incident is not the same as one eroded by chronic instability, and a policy that treats them identically will occasionally pause the wrong work at the wrong time — which is why the exception process is part of the design rather than a weakness in it.

They also require honest measurement, which is politically uncomfortable. An SLO measured where it flatters the team is worse than no SLO, and the pressure to measure conveniently is real and constant.

The trade is flexibility and comfortable measurement in exchange for a prioritisation argument that resolves itself. The mechanism is worth adopting only where the organisation is prepared to honour the consequence; where it is not, the effort is better spent on the SLO alone, used as information rather than as a rule.

Interview question

"Our budget has been fully unspent for three consecutive quarters and leadership is delighted. Tell me why that might be a problem, what you would recommend, and what you would expect to happen to our incident count if they took your advice."