What is Error Budget?
Also called reliability budget.
An error budget is the amount of unreliability a service is permitted over a period, derived directly from its reliability target. If the target is 99.9 percent of requests succeeding in a month, the budget is the remaining 0.1 percent. Spending within budget is normal; exhausting it triggers an agreed change in how the team operates.
The arithmetic is deliberately simple. Subtract the target from 100 percent and apply it to the volume or time window in question. A monthly 99.9 percent target permits roughly 43 minutes of full unavailability, or the equivalent share of failed requests spread across the month. Expressing the budget in requests rather than minutes is usually more meaningful, since a failure during peak traffic harms far more users than the same duration overnight.
The concept's purpose is to settle the recurring argument between shipping speed and stability with a number instead of seniority. While budget remains, the team is free to release, experiment, and take calculated risks. When the budget is exhausted, a pre-agreed policy takes effect, commonly a freeze on feature releases until reliability work restores headroom. The policy must be agreed in advance to have any force.
Burn rate refines the picture. Consuming a month's budget evenly is sustainable; consuming half of it in one hour is an emergency even though the monthly number still looks fine. Alerting on burn rate over short and long windows simultaneously is the standard way to page for fast severe events while still catching slow steady degradation that never trips a simple threshold.
For agent systems the hard part is defining what counts as a failure. Crashes and timeouts are unambiguous. A run that completes but produces a wrong or unusable answer is a real user-facing failure that no infrastructure metric registers. Teams that want a meaningful budget must define a quality-based success criterion, which usually means feeding an evaluation signal into the same accounting as the availability signal.
Key points
- Budget equals one hundred percent minus the reliability target
- Converts the ship-versus-stability debate into an agreed number
- The consequence of exhaustion must be agreed before it happens
- Burn rate alerts catch fast severe and slow steady degradation
- Agent failure includes wrong answers, not only crashes
In practice
A team sets a 99.5 percent monthly success target for agent runs, where success means the run finished and passed an automated output check. Across 400,000 runs the budget is 2,000 failures. A tool integration regression burns 1,300 in a single afternoon. With 65 percent of the month's budget gone in week two, the standing policy pauses new releases until the integration is fixed and verified.