What is Error Budget?

#How error budgets work

The budget is the complement of the SLO. Subtract the target from 100% and apply it to the measurement window: 99.9% over thirty days yields about forty three minutes, 99.99% yields about four minutes.

Request-based SLOs express the budget as allowed unsuccessful requests rather than minutes of downtime. Consumption is tracked continuously against real incidents. The budget then drives policy. While budget remains, the team ships at normal pace, because unused reliability headroom is permission to take risk. When the budget is exhausted, release policy tightens and reliability work takes priority until the budget recovers.

#Why error budgets matter

The error budget resolves the standing argument between shipping features and maintaining stability by making it a number instead of a debate.

• Shared objective: product and engineering optimize against the same figure.
• Risk permission: remaining budget is explicit license to deploy and experiment.
• Automatic escalation: exhaustion triggers a predefined response, not a negotiation.
• Honest targets: a budget consistently exhausted means the SLO does not match the architecture.

#Limits and misuse

Budgets only function if exhaustion actually changes behavior. An organization that blows through its budget and ships anyway has a reporting metric rather than a control, and everyone learns quickly that the policy is decorative.

The other failure is treating the budget as a quota to spend. It is a ceiling, not a target, and burning it deliberately on avoidable failures because it is available misreads the intent entirely.

#Error budget vs SLO

The SLO is the target: 99.9% of requests succeed. It states the goal in positive terms.

The error budget is the same statement inverted into a consumable quantity, and the inversion is what makes it operationally useful. Nobody knows what to do with a percentage target on a Tuesday afternoon. Everybody understands that thirty of forty three allowed minutes are gone with three weeks left in the window. The SLO defines the line, the budget tells you where you are relative to it right now.

#Key takeaways

• The error budget is the complement of the SLO expressed as a consumable quantity of failure.
• Remaining budget is explicit permission to take deployment risk; exhaustion triggers a predefined policy change.
• A budget with no enforcement is a reporting metric rather than a control, and teams learn that immediately.
• It is a ceiling rather than a quota, so deliberately spending it on avoidable failures misreads the mechanism.

#Frequently asked

What happens when the error budget is exhausted?

A predefined policy takes effect, typically a freeze on non essential releases with engineering effort redirected to reliability until the window rolls forward.

Should budgets reset monthly or roll continuously?

Rolling windows avoid the perverse incentive of a fresh budget on the first of the month. A thirty day rolling window is common.

What if the budget is never consumed?

The SLO may be set too conservatively. Persistent unused budget suggests the team could ship faster or is spending on reliability beyond what users need.

#Sources

• Google SRE: embracing risk