Error Budget

Development teams want to ship features quickly, and every change carries some risk of breaking something. Operations teams want stability, and the safest change is no change at all. Without a shared rule, this tension turns into arguments, release freezes and blame after every outage. An error budget provides that rule. If a service aims to succeed for 99.9% of requests, then 0.1% of requests are allowed to fail. That allowance is the budget. While the budget remains, teams can take risks and ship quickly. When it is used up, the agreed response is to slow down and invest in reliability. The budget turns reliability from a constant argument into a shared, measurable resource.

Error budgets are one of the defining ideas of site reliability engineering, described in Google's SRE books as a way to align product and operations teams around data rather than opinion. They follow directly from service level objectives: the budget is simply one minus the SLO, over the same time window. For a 99.9% monthly availability objective, the budget is about 43 minutes of downtime in a 30-day month, or the equivalent share of failed requests. For SRE teams, product managers and engineering leaders, error budgets turn reliability from a vague goal into a resource that can be spent deliberately.

Definition of Error Budget

An error budget is the maximum amount of unreliability, calculated as one minus the service level objective over the SLO's time window, that a service may experience before it fails its objective, together with an agreed policy for how teams change their behavior as the budget is consumed.

It is derived from service level objectives (SLOs), is a central practice in site reliability engineering (SRE) and is often spent on risky changes such as releases, which can be made safer with canary deployment.

How Error Budgets Are Calculated

Start with the SLO, such as 99.9% of requests succeeding over 30 days.

The error budget is the remaining 0.1%. If the service handles 10 million requests in that period, up to 10,000 can fail before the SLO is missed.

For time-based availability, a 99.9% monthly target allows about 43 minutes of downtime, while 99.99% allows about 4 minutes.

Teams track how much of the budget has been used so far in the window, and how quickly it is being used, known as the burn rate. A burn rate of one means the budget will be used up exactly at the end of the window, while higher rates mean it will run out early.

Error Budget Policies

An error budget policy describes what happens as the budget is consumed. It is agreed in advance by engineering and product leaders.

Typical policies allow normal releases while budget remains, require extra caution or review as it runs low and pause risky feature releases when it is exhausted, with effort redirected to reliability.

Policies often include exceptions, such as allowing urgent security fixes, and a process for escalating disagreements to senior leaders. The policy should be short, written down and agreed before it is needed, since negotiating it during a crisis rarely works.

Importance of Error Budgets in Delivery and Engineering Operations

Error budgets align incentives. Product and engineering teams share an objective way to decide when to ship and when to stabilize.

They encourage healthy risk-taking. When reliability is well above target, teams know they can move faster and experiment.

They also make reliability a priority when it matters. Exhausting the budget is a clear, agreed signal to invest in fixing problems, rather than an argument about whether things are bad enough.

Error Budgets and Financial Management

Spending error budget on frequent releases lets the business deliver value faster when systems are healthy.

Pausing features when the budget is exhausted protects revenue and customer trust from repeated outages.

Error budgets show where reliability investment is needed, directing engineering spending to the services that are struggling.

They also prevent over-investment, since a service consistently far within its budget may be more reliable, and more expensive, than it needs to be.

Common Challenges

Policies without leadership support collapse the first time a business deadline conflicts with an exhausted budget.

SLOs that do not reflect user experience produce error budgets that do not either, so the budget can be spent on problems users never notice or missed on problems they do.

Teams sometimes hoard budget out of caution, slowing delivery unnecessarily, or treat any spending as failure. Budgets shared by several teams can be hard to manage, since one team's risky change can use up budget that others were counting on.