Error budget

An error budget is the quantitative allowance for unreliability in a system, defined as the complement of a service level objective (SLO). If a service commits to 99.9% availability — three nines — its error budget is 0.1% downtime, or approximately 43.8 minutes per month. The error budget is not a failure target; it is a resource to be spent. It represents the organization's explicit acknowledgment that perfect reliability is neither achievable nor desirable, and that the pursuit of ever-higher availability carries opportunity costs that must be weighed against other engineering priorities.

The concept was developed within Google's Site Reliability Engineering (SRE) practice as a mechanism to resolve the chronic conflict between development teams, who want to ship features rapidly, and operations teams, who want to maintain stability. The error budget replaces political negotiation with a quantitative contract: as long as the service remains within budget, development proceeds at full velocity. When the budget is exhausted, feature development halts and all engineering effort shifts to reliability work until the budget regenerates.

The Mathematics of Error Budgets

Error budgets are typically calculated over a fixed window — commonly 30 days or a quarter. For an availability SLO of 99.9% over 30 days:

Total minutes in 30 days: 43,200
Allowed downtime: 43.2 minutes
Error budget: 43.2 minutes of unavailability

The budget is consumed by any event that causes the service to fail to meet its SLO: deployment failures, infrastructure outages, configuration errors, traffic spikes, and dependency failures. The consumption is measured against the SLO's evaluation metric, which may be request success rate, latency threshold compliance, or a composite of multiple indicators.

A critical design question is whether the budget should be calculated on a rolling window or a calendar window. Rolling windows (e.g., the last 30 days) smooth out seasonal variation and prevent edge effects at month boundaries. Calendar windows (e.g., January 1–31) align with business reporting cycles but can create perverse incentives: a team that exhausts its budget on January 15th might be tempted to defer reliability work until February 1st, when the budget resets. Google's original SRE book recommends rolling windows for this reason.

Error Budgets as Economic Instruments

The error budget is best understood not as an engineering metric but as an economic instrument. It creates a market for reliability within the organization, with the error budget as the scarce resource and engineering effort as the currency. Teams that spend their budget wisely — by investing in canary deployments, automated rollback, and robust testing — can ship more features while maintaining the same reliability. Teams that spend their budget carelessly — by deploying untested code, ignoring alerts, or accumulating technical debt — find themselves in reliability debt, forced to halt feature development until they recover.

This market mechanism has several advantages over traditional governance:

Autonomy: The team decides how to spend its budget. It can choose to ship a risky feature that consumes 50% of the budget, or it can conserve the budget for unforeseen failures. The decision is decentralized.
Transparency: The budget state is visible to all stakeholders. Product managers can see how much budget remains before planning a major launch. Executives can see which teams are consistently in budget deficit.
Incentive alignment: The team is rewarded for reliability engineering not by managerial fiat but by the increased velocity that reliable systems enable. A team with a healthy error budget ships more features than a team in deficit.

But the market analogy also reveals the error budget's limitations. Markets assume rational actors with complete information, and engineering teams rarely satisfy either assumption. A team may not know the reliability cost of a feature until after deployment. A team under pressure to deliver may consciously choose to exhaust the budget, gambling that no major failure will occur before the window resets. The error budget is a constraint, not a solution; it makes the tradeoff visible but does not eliminate the tension.

Error Budget Policies

Organizations implementing error budgets typically define explicit policies for budget exhaustion. A common policy structure includes three tiers:

Green: The service is above 90% of its budget. Normal operations continue; feature development proceeds at full velocity.
Yellow: The service has consumed 50–90% of its budget. The team increases scrutiny of deployments, requires additional review for high-risk changes, and may defer non-critical feature work.
Red: The service has exhausted 100% of its budget. All feature development stops. The team focuses exclusively on reliability work: fixing known bugs, reducing alert noise, improving monitoring, and conducting postmortems. No exceptions.

The strictness of the red-tier policy is a cultural indicator. Organizations that enforce it rigorously signal that reliability is non-negotiable. Organizations that routinely grant exceptions signal that the error budget is theater — a metric that is tracked but not honored. The effectiveness of error budgets depends entirely on organizational commitment to the policy.

Critiques and Edge Cases

Error budgets assume that reliability is measurable and that the SLO captures what users care about. Both assumptions fail in practice.

Measurability: Not all failures are equally visible. A silent data corruption bug may consume no error budget — the requests succeed, the responses are wrong — while a visible outage that triggers automatic failover consumes budget without user impact. The error budget measures availability, not correctness.

User impact: The error budget treats all failures as equivalent, but users experience failures differently. A 0.1% failure rate distributed uniformly across all users is less damaging than a 0.1% rate concentrated in a high-value segment. The error budget has no concept of user segmentation or business impact weighting.

Cascading failures: A service may be within its own error budget while causing a dependent service to exceed its budget. The error budget is a local metric in a network of interdependent services, and local optimization does not guarantee global optimization. A database that fails 0.05% of the time may be within budget, but if that 0.05% correlates with peak traffic hours, it may cause the application layer to fail 0.5% of the time.

Temporal correlation: The error budget does not distinguish between correlated and uncorrelated failures. Ten one-minute outages spaced evenly across a month consume the same budget as one ten-minute outage during a product launch. The business impact is vastly different, but the budget is identical.

The Deeper Problem

The most profound critique of error budgets is that they treat reliability as a scalar quantity when it is actually a vector. A system can be highly available but slow, or fast but inconsistent, or consistent but expensive. The error budget reduces this multidimensional space to a single number — availability — and optimizes that number at the expense of other dimensions that may matter more to users.

This reduction is not accidental; it is necessary. Organizations cannot optimize in ten dimensions simultaneously. The error budget is a heuristic — a simplified model of a complex reality — and like all heuristics, it fails when the simplification matters. The responsible practitioner uses error budgets as a guardrail, not as a goal, and remains alert to the dimensions of reliability that the budget does not capture.

The error budget is a lie that tells the truth. It lies because it pretends that reliability is a single number. It tells the truth because it makes explicit the tradeoff that every organization makes implicitly: between the speed of change and the stability of service. The organizations that succeed are not those with the tightest budgets. They are those that understand what their budgets hide.