An error budget is the amount of unreliability a system is allowed to have over a given period, before something changes about how the team operates. It comes directly out of the SLO you set: if your service level objective is 99.9% availability over 30 days, your error budget is the remaining 0.1%, expressed as actual downtime or actual failed requests you are allowed before you have "spent" it.
What changed in 2026
- Multi-window, multi-burn-rate alerting became the standard practice, rather than a single threshold alert, letting teams distinguish a fast, severe burn from a slow, chronic one that both deserve different responses.
- Error budgets expanded beyond availability into latency, correctness, and even AI system quality metrics, as more teams applied the same spend-and-replenish framework to reliability dimensions beyond simple uptime.
- Error budget policies got tied more directly into release automation, with CI/CD pipelines automatically blocking risky deploys when a budget is critically low, rather than relying on a human to remember the policy.
- Cross-team error budget dashboards became more common in organizations running many interdependent services, since one team's outage can consume a downstream team's budget too.
The math behind an error budget
Start with an SLI (service level indicator) — a specific, measurable signal like the percentage of requests that succeeded. Set an SLO (service level objective) — the target for that SLI, like 99.9% over 30 days. The error budget is what is left: 0.1% of the period, which for a 30-day window works out to roughly 43 minutes of full downtime, or the equivalent in partial failures across a larger number of requests.
| SLO target |
Error budget over 30 days (approx.) |
| 99.0% |
~7.3 hours |
| 99.9% |
~43 minutes |
| 99.95% |
~21.6 minutes |
| 99.99% |
~4.3 minutes |
These figures assume full downtime equivalent; in practice, partial degradation (some requests failing while others succeed) consumes budget proportionally, not as all-or-nothing outages. Treat the table as illustrative and recompute for your own SLO and window before using it operationally.
How teams actually use the budget
The point of an error budget is not to track a number for its own sake — it is to make a specific decision easier: should we ship this risky change right now, or should we prioritize stability work first? When the budget has plenty left, teams have room to take reasonable risks: faster releases, experiments, less conservative rollout strategies. When the budget is nearly exhausted, the sensible response is to slow down — freeze non-critical releases, prioritize the reliability work that is burning the budget, and get back into a healthy range before resuming normal velocity.
This is deliberately not a punishment system. Spending the budget is expected and even desirable up to the limit; a team that never spends any error budget is arguably being too conservative and shipping too slowly relative to what users actually need.
Error budget policy: what happens at zero
A useful error budget system needs an agreed-upon policy for what happens when the budget runs out, decided in advance rather than argued about mid-incident. Common policies include freezing feature releases until the budget recovers, requiring extra approval for risky changes, or automatically reprioritizing the team's work toward reliability fixes. The policy only works if it is followed consistently — an error budget everyone quietly ignores when it hits zero is not actually constraining anything.
Common pitfalls
- Setting the SLO without asking what users actually need. A stricter-than-necessary SLO burns budget on failures nobody would have noticed, and constrains velocity for no real user benefit.
- Measuring the wrong SLI. Server-side uptime can look fine while users experience real failures from client-side issues, CDN problems, or partial degradation the SLI does not capture.
- Ignoring burn rate. A budget that would normally last 30 days but is on pace to be exhausted in 3 days is a very different situation than slow, steady consumption, even if the remaining budget number looks the same at a glance.
- No agreed policy for what happens at zero, which turns every budget exhaustion into an ad hoc argument instead of a predictable process.
FAQ
Is an error budget the same as an SLA?
No. An SLO is an internal target; an SLA is an external, often contractual, commitment to customers, usually looser than the internal SLO to leave margin for error. The error budget is derived from the SLO, not the SLA.
Who owns the error budget policy?
Usually a shared agreement between the team building the service and whoever represents product or business priorities, since the policy directly trades off velocity against reliability — a decision neither side should make unilaterally.
What is a healthy SLO to start with?
There is no universal number; it depends entirely on what your users need and what failure actually costs. Start by measuring your current reliability honestly, then set a target slightly above it rather than picking an arbitrary industry figure. Related concept: a service level objective is the target itself, separate from the budget derived from it.
Does a 100% SLO make sense for critical systems?
Almost never in practice. 100% is unachievable over any meaningful period and leaves zero room for routine risk like deploys, dependency failures, or infrastructure maintenance — even the most critical systems set a target below 100%.
Where to go next