The Most Important Concept
The Error Budget is the concept that transforms SLOs from passive measurements into an active decision-making tool. It changes the conversation from "should we push this feature?" to "do we have budget to take this risk?"
The math is simple:
$$\text{Error Budget} = 100\% - \text{SLO}$$
- If your SLO is 99.9% success over a 30-day window, your Error Budget is 0.1% of requests that are allowed to fail.
- If your SLO is 99.5%, your Error Budget is 0.5%.
A higher SLO means a smaller error budget — less room for failures, less room for risk.
Error Budget as a Shared Resource
Think of the error budget as a shared bank account that both developers and operations teams draw from. Every failed request, every slow response, every deployment-caused outage — all of it spends from the same budget.
This creates aligned incentives:
- Developers want to ship features. Features require deployments. Deployments carry risk. If there's budget remaining, they can take that risk.
- Operations/SRE teams want stability. If the budget is nearly exhausted, they have data-backed authority to say "no new deployments until we recover."
Neither side is making a subjective judgment. Both sides are looking at the same number.
The Error Budget Policy
The error budget only works if there is a written, agreed-upon policy that defines what happens at different consumption levels. Without a policy, the budget is just a number on a dashboard.
A typical policy looks like this:
| Budget Remaining | Action |
|---|---|
| > 50% | Normal operations. Feature deployments proceed as planned. |
| 25–50% | Increased caution. Deployments require additional review. |
| < 25% | Deployment freeze. All engineering effort redirected to reliability. |
| 0% (exhausted) | Full incident review required before any new feature work resumes. |
This policy must be agreed upon by engineering leadership, product management, and the SRE team before an incident — not negotiated in the middle of one.
Calculating the Budget in Real Numbers
Abstract percentages are hard to reason about. Convert them to concrete counts:
- SLO: 99.9% success over 30 days
- Traffic: 100 requests/second
- Total requests: 100 × 60 × 60 × 24 × 30 = 259,200,000 requests/month
- Error Budget (0.1%): 259,200,000 × 0.001 = 259,200 allowed failures/month
- Per day: ~8,640 allowed failures/day
- Per hour: ~360 allowed failures/hour
Now the question "can we afford this deployment?" becomes concrete: "Does this deployment risk causing more than 360 errors in the next hour?"