Resilience Budget
A resilience budget reserves capacity, error tolerance, and engineering time in advance so failures can be absorbed without breaching user-facing targets.
Definition
A resilience budget is a deliberate allocation of headroom, redundancy, and response capacity reserved to absorb failures and recover within agreed reliability targets.
Context and scope
Used in capacity and quarterly planning to stop teams from consuming all redundancy and on-call capacity during normal operations.
Common misconceptions
- A resilience budget is simply an error budget under another name
- Reserves can be reclaimed whenever utilization looks low
- Buying more redundancy is the only way to grow the budget
Anti-patterns
- Running production at ninety-five percent utilization and calling the remainder a buffer
- Cutting on-call capacity to fund feature work
- Declaring a budget without measuring how incidents consume it
Related concepts
Related examples
Authoritative source
The idea
A resilience budget is the part of a system’s capacity and a team’s time deliberately held back for failure. It has three parts: capacity headroom so surviving replicas can absorb traffic after a loss, error tolerance so a bad hour does not exhaust the reliability target, and response capacity so engineers can investigate without abandoning all planned work. The budget is consumed when failures happen; it is replenished by design, not by optimism.
Why a separate budget
An error budget measures acceptable unreliability against an SLO. It does not describe whether the architecture can survive the failure that produces those errors. A service can stay within its error budget while running with no spare capacity, so the next instance loss becomes an outage. A resilience budget makes that hidden dependence explicit. It also covers human capacity: a team with no slack cannot run a long incident and a release in the same week.
What it covers
Capacity reserves include N+1 or N+2 redundancy, autoscaling headroom, queue capacity, and database failover capacity. Error tolerance includes the allowed burn rate and the policy for pausing releases. Response reserves include on-call rotation size, runbook maintenance, and game-day time. Compared to a pure error budget, this framing ties reliability promises to the resources needed to keep them.
Consumption and governance
Measure how much headroom a failure actually consumes. After an incident, ask whether the reserve was sufficient and whether the response depleted planned work. Review the budget quarterly with product and operations. If feature work consistently eats the reserve, reliability is being funded by borrowing from future incidents.
Limits
The budget is a planning heuristic, not a precise accounting unit. Its value comes from making trade-offs visible. For example, a team may choose to keep twenty percent spare capacity rather than maximize utilization, and defend that choice with outage cost data.