Error Budget

Origin & evolution

The error budget is a load-bearing idea in Google's Site Reliability Engineering practice, set out in the chapter Embracing Risk of the SRE book (2016). The arithmetic is deliberately plain: the budget is 100% minus the objective. A service with a 99.9% objective serving a million requests in four weeks has a budget of a thousand failed requests over that window.

The mechanism it replaces is an old standoff. Developers want to ship; operations wants to stay stable; each accuses the other of bad faith. The error budget removes the politics by making "how reliable" a number both teams agreed to in advance. While budget remains, the developers may spend it on risk🎲RiskComplianceA risk to the product or businessView reference →: new features⭐FeatureProduct SpecificationA product capability or featureView reference →, faster releases🚢ReleaseProduct SpecificationA shipped version of the productView reference →, bolder experiments🧫ExperimentValidationA test designed to validate a hypothesisView reference →. The budget aligns incentives by giving both sides the same scoreboard.

The SRE Workbook (2018) turned the number into a policy with teeth. A typical error budget policy says that while a service is within budget, releases proceed; once the budget for the window is exhausted, all changes except security and critical fixes halt until reliability recovers. The freeze is the part that gives the budget real authority. A budget you can overspend without consequence is a suggestion, and the policy is what converts the suggestion into a brake.

How it works in practice

A team runs a checkout service to a 99.95% availability objective, measured over a 28-day window against an indicator of successful requests over valid requests. That objective grants a budget of 0.05%, roughly twenty minutes of total unavailability across the four weeks, or its equivalent in scattered failed requests.

For the first three weeks they spend the budget on velocity, shipping daily, accepting that an occasional bad deploy burns a few minutes of budget. In week four a botched migration causes a fifteen-minute partial outage, and the burn-rate alert fires: most of the remaining budget has gone in one incident🚨IncidentDevOps & PlatformA production incidentView reference →. The policy triggers automatically. Feature releases freeze, the on-call rolls back, and engineering effort moves to the reliability work that had been deferred. No manager had to win an argument; the budget made the call, and it resets at the start of the next window.

Error budget vs. its neighbours

• Service level objective🥅Service Level ObjectiveDevOps & PlatformA service level objective (SLO)View reference →: the objective is the promise (99.95% over a quarter); the budget is its inverse, the failure that promise tolerates. Set the objective and you have defined the budget in the same stroke. One states the goal, the other states the slack.
• Service level indicator🌡️Service Level IndicatorDevOps & PlatformA service level indicator (SLI)View reference →: the indicator is the live measurement of how the service is performing. The budget is computed by subtracting the objective from the indicator's running result: it is the gap left between what you achieved and the worst you promised.
• Release: a release is a discrete change pushed to production, and it is the main thing a budget governs. A healthy budget lets releases flow; an exhausted one stops them. The budget turns "should we ship?" from a judgement call into a check against a balance.

In the graph

In the Unified Product Graph, an error budget sits in the operations region as the derived consequence of a reliability target. Its defining edge is its source: an objective budgets as an error budget (service_level_objective_budgets_as_error_budgetService Level Objectivebudgets asError Budgethierarchy). Modelling the budget as its own node, rather than a property of the objective, lets the graph attach what depends on it, the release policy it gates and the incidents that drained it, so the budget reads as a live account rather than a fixed figure. That structure mirrors how the budget works in practice: a single number, owned jointly, that decides whether the next change ships.