What Is an Error Budget?

An error budget is the complement of an SLO target. If your SLO is 99.9% availability over a 30-day window, your error budget is 0.1% — approximately 43 minutes of allowed downtime per month. That is not a problem to eliminate. It is a resource to spend deliberately.

The budget framing matters. Treating that 43 minutes as "the amount we can fail" produces reactive operations: incidents burn budget, the team scrambles, the budget recovers, repeat. Treating it as a resource produces deliberate operations: the team decides how to spend it — new deployments, experiments, planned maintenance — and the budget functions as a constraint on how much risk to take at any given time.

Error budgets apply to time-based SLOs (availability over a period) and to request-based SLOs (success rate over a number of requests). For a service handling one million requests per month with a 99.9% success rate SLO, the budget is 1,000 allowed failures per month. When the team has used 900 of those failures, the budget is nearly spent and behavior should change.

The fundamental mechanism: when the budget is full (no incidents, SLO comfortably met), deploy as fast as you want. When the budget is depleted (the SLO window's tolerance has been used up), slow down and fix things. This aligns product and engineering incentives without a manager mediating every reliability-vs-feature conversation.

A product team that wants to ship a risky new feature has an incentive to maintain the error budget — if the budget is depleted by previous deployments, the policy blocks the new feature too. That creates a natural pressure toward reliability that does not require the SRE team to be the permanent bearer of bad news.

In practice, most teams track their budget consumption in a dashboard: current reliability vs. SLO target, percentage of budget consumed for the current window, burn rate (how fast the budget is being spent). When burn rate is high, the team investigates before the budget depletes, not after.

An error budget without a policy is a dashboard metric. The policy is the document that specifies what changes when the budget depletes: which deployments are blocked, which are allowed (security patches, bug fixes), who approves exceptions, and what triggers the policy to lift (budget recovery over a defined window, postmortem completed and action items closed).

A well-designed error budget policy is written before the budget depletes, reviewed by product and engineering leadership, and referenced during incidents rather than negotiated in the moment. The policy removes the need for ad-hoc conversations about whether a particular deployment is acceptable given the current reliability state.

Policies that are too strict become obstacles: every minor deployment requires a waiver request and the policy gets ignored. Policies that are too loose have no operational effect. The right calibration reflects the business cost of reliability breaches for the specific service and the team's current capacity to recover quickly when things go wrong.

The platform team owns two things in the error budget system. First, the tooling: SLO dashboards, error budget tracking, alerting that fires before the budget depletes rather than after, and the templates that make it straightforward for a new service to define its first SLO and start tracking its budget.

Second, the policy enforcement mechanism: the automated gate that blocks deployments when the error budget policy criteria are met. Without automation, the policy depends on someone checking the dashboard before every deployment — which means it gets skipped when teams are moving fast. An automated deployment gate that checks current budget consumption before allowing a production deploy makes the policy real.

The SLO values themselves — the targets that determine how large each service's budget is — are not the platform team's to set unilaterally. Those values require product context the platform team does not have: what reliability means to users, what a breach costs in business terms, and what the service is actually capable of achieving at current maturity.