Error Budget

An engineering team was in constant conflict. Product managers pushed for faster feature development. SRE engineers pushed for more stability work. Every sprint planning devolved into an argument about priorities. Both sides had valid points. Neither had data.

Then they adopted error budgets. The SLO was 99.9%, giving them 43.8 minutes of allowed downtime per month. In January, they used 10 minutes. Error budget healthy. Product wins, ship features aggressively. In February, a bad deployment burned 35 minutes by day 12. Error budget nearly exhausted. SRE wins, freeze deployments, focus on stability.

The arguments stopped. Not because people changed their minds, but because the decision was no longer subjective. The error budget provided an objective, data-driven framework for balancing speed and reliability. When the budget is healthy, move fast. When it's depleted, slow down. No opinions needed.

The error budget is the inverse of your SLO, the amount of unreliability you've agreed to tolerate.

Calculation:

• SLO: 99.9% availability over 30 days
• Error budget: 100% - 99.9% = 0.1%
• In time: 0.1% of 30 days = 43.2 minutes
• In requests: if you serve 10 million requests/month, 0.1% = 10,000 failed requests allowed

Error budget consumption happens through:

• Outages, service is completely down
• Degradation, slow responses that breach the latency SLI
• Partial failures, errors affecting a subset of users
• Planned maintenance, if it impacts users, it burns budget

Tracking error budget over time:

This team ended the month at 54% remaining, comfortable, but the two incidents used almost half the budget. If another incident of similar size had occurred, they'd have been close to breaching the SLO.