An error budget is the amount of unreliability a service may have within a time window without breaking its SLO. It equals 100 percent minus the SLO target: a 99.9 percent availability SLO over 30 days allows 0.1 percent bad events, about 43 minutes of full downtime. Teams use the remaining budget to choose between shipping features and reliability work.
What is an error budget?
An error budget is the share of requests, or the amount of time, that is allowed to fail within an SLO window. It turns a reliability target into something a team can spend. If the SLO says 99.9 percent of requests over 30 days must succeed, then 0.1 percent may fail. That 0.1 percent is the budget.
The idea, popularized by Google's Site Reliability Engineering practice, rests on a simple observation: 100 percent reliability is neither achievable nor desirable. Every additional nine costs more engineering effort and slows down change, while users often cannot tell the difference beyond a certain point. An error budget makes that trade-off explicit. As long as budget remains, the team can release, experiment and take reasonable risks. When the budget is exhausted, reliability work takes priority.
How to calculate an error budget
error_budget = 1 - SLO_target
allowed_bad_events = error_budget * valid_events
remaining_budget = 1 - (actual_bad_events / allowed_bad_events)For time-based thinking, the budget can be expressed as equivalent full downtime in a 30-day window:
| SLO target | Error budget | Equivalent downtime per 30 days |
|---|---|---|
| 99 % | 1 % | 7 h 12 min |
| 99.5 % | 0.5 % | 3 h 36 min |
| 99.9 % | 0.1 % | 43 min 12 s |
| 99.95 % | 0.05 % | 21 min 36 s |
| 99.99 % | 0.01 % | 4 min 19 s |
An illustrative example with a request-based SLI: a service handles 20 million valid requests in 30 days with a 99.9 percent SLO. The budget is 20,000 failed requests. If 8,000 have failed after two weeks, 60 percent of the budget remains. Partial failures count too: an hour in which 2 percent of requests fail consumes about as much budget as 1.2 minutes of total outage at the same traffic.
Burn rate and alerting
The burn rate describes how fast the budget is consumed relative to the window. A burn rate of 1 uses up exactly the whole budget by the end of the window. A burn rate of 14.4 sustained for one hour consumes 2 percent of a 30-day budget, which is a strong signal for a page. Common multi-window alert policies combine a fast window for acute problems with a slower window for gradual degradation, for example:
- Page: burn rate above 14.4 over 1 hour, confirmed over 5 minutes.
- Page: burn rate above 6 over 6 hours, confirmed over 30 minutes.
- Ticket: burn rate above 1 over 3 days.
These values are widely used starting points, not universal rules. Adjust them to your traffic and tolerance for noise.
The error budget policy
A budget only changes behavior if everyone has agreed in advance what happens when it runs low. An error budget policy is a short, written agreement between engineering, product and operations. Typical elements:
- Budget healthy: normal release cadence, experiments and planned maintenance are fine.
- Budget below a threshold, for example 25 percent: releases need extra review, risky migrations are postponed, canary stages are extended.
- Budget exhausted: feature releases pause except for fixes and security patches. The team works on the top causes of budget consumption until the rolling window recovers.
- Exceptions: who may override the policy and how that decision is documented.
Our blog post on SLOs in practice and release gates shows how such a policy can be wired into a delivery pipeline.
Best practices
- Choose SLO targets based on what users need, not on what the system currently achieves. A target that is always met has a budget nobody ever uses.
- Track budget consumption per cause, such as deployments, dependencies or infrastructure, to see where reliability work pays off.
- Correlate budget drops with deployments to catch regressions and support automated rollbacks.
- Review budgets regularly in planning, not only during incidents.
- Spend budget deliberately: planned maintenance or chaos experiments are legitimate uses.
Common mistakes
- Defining a budget without a policy, so nothing changes when it is exhausted.
- Using the error budget as a performance metric for individuals, which encourages hiding incidents.
- Excluding failures of dependencies from the budget, even though users experience them.
- Setting the same target for every service regardless of its importance.
- Resetting the budget on calendar boundaries and ignoring a rolling window, which invites risky releases at the start of each month.
How Obseria helps
Obseria calculates error budgets for every SLO from your SLIs, shows remaining budget and burn rate over rolling windows and alerts with multi-window burn-rate rules. Deployment markers show which releases consumed budget, and Automation can trigger rollbacks or block releases when a policy threshold is crossed.
