An error budget is the maximum amount of unreliability a service is allowed to accumulate over a defined period, calculated as 100 percent minus the service level objective (SLO). In observability and site reliability engineering, it turns a reliability target into a measurable allowance: a service with a 99.9 percent availability SLO over 30 days may fail 0.1 percent of requests or about 43 minutes of that window.
The concept changes how teams discuss reliability. Instead of treating every failure as unacceptable, the error budget defines how much failure is acceptable and makes the remaining budget a shared signal for deciding whether to ship new features or invest in stability.
How an error budget is calculated
An error budget is derived from three elements: a service level indicator (SLI), an SLO target and a compliance window. The SLI is a measured ratio of good events to valid events, such as successful HTTP requests divided by all requests, or requests faster than 300 milliseconds divided by all requests.
The budget equals one minus the SLO, applied either to events or to time. In a request-based model, a 99.9 percent SLO over 50 million requests allows 50,000 failed requests. In a time-based model, the same target over a 30-day window allows about 43.2 minutes of bad time. Request-based budgets are usually preferred because they weight failures by actual user impact.
The following table shows how quickly the allowance shrinks as the target rises.
| SLO target | Error budget share | Allowed downtime per 30 days |
|---|---|---|
| 99 percent | 1 percent | About 7.2 hours |
| 99.5 percent | 0.5 percent | About 3.6 hours |
| 99.9 percent | 0.1 percent | About 43 minutes |
| 99.95 percent | 0.05 percent | About 22 minutes |
| 99.99 percent | 0.01 percent | About 4.3 minutes |
Each additional nine reduces the budget by a factor of ten, while the engineering cost to achieve it usually grows much faster. This is why a target of 100 percent is considered the wrong goal for almost every service: it leaves no budget for change and exceeds what users can perceive through their own networks and devices.
Error budgets within the reliability vocabulary
The error budget is one link in a chain of related concepts, and confusing them leads to poorly designed targets. The table separates the terms.
| Term | Meaning | Example |
|---|---|---|
| SLI | Measured indicator of service behavior | Share of requests answered without error |
| SLO | Internal target for an SLI over a window | 99.9 percent over 30 days |
| SLA | Contractual commitment with consequences | Service credits below 99.5 percent |
| Error budget | Allowed shortfall below the SLO | 0.1 percent of requests |
| Burn rate | Speed of budget consumption relative to plan | A rate of 10 empties the budget in 3 days |
An SLA is normally set looser than the internal SLO, so the error budget is exhausted and acted upon before contractual penalties apply. The SLI itself comes from observability data: metrics provide the counts, while logs and traces explain why individual requests failed.
Burn rate and budget-based alerting
The burn rate expresses how fast the budget is being consumed: a burn rate of 1 uses exactly the whole budget over the full window, while a burn rate of 14.4 sustained for one hour consumes about 2 percent of a 30-day budget. Alerting on burn rate links paging directly to user impact instead of to raw thresholds such as CPU usage.
A widely used scheme is multi-window, multi-burn-rate alerting, which combines a long window that confirms significance with a short window that confirms the problem is still happening.
| Burn rate | Long window | Short window | Budget consumed | Response |
|---|---|---|---|---|
| 14.4 | 1 hour | 5 minutes | 2 percent | Page immediately |
| 6 | 6 hours | 30 minutes | 5 percent | Page |
| 1 | 3 days | 6 hours | 10 percent | Ticket for working hours |
This structure catches fast, severe outages within minutes and slow degradations within hours or days, while the short window ensures that alerts reset soon after recovery. The exact numbers are conventions, not laws, and teams adjust them to their window length and on-call capacity.
Error budget policies in practice
A budget has value only when an agreed error budget policy states what happens as it is consumed. The policy is negotiated in advance between product, development and operations, so decisions during an incident are not improvised.
| Budget state | Release practice | Engineering priority |
|---|---|---|
| Healthy, more than 50 percent left | Normal release cadence | Feature work, controlled experiments |
| Under pressure, 10 to 50 percent left | Smaller releases, longer canary phases | Address top sources of errors |
| Exhausted | Freeze except fixes and security patches | Reliability work until budget recovers |
Unused budget is also information. A service that consistently ends the window with most of its budget unspent may be moving too cautiously, and the team can afford faster releases or riskier experiments. Some teams deliberately spend budget on planned maintenance or failure testing.
Pitfalls and misconceptions
Error budgets fail most often because of poorly chosen indicators or an unenforced policy, not because of arithmetic.
- Measuring the wrong thing: server-side success can look perfect while clients fail at the network or load balancer layer.
- Targets copied from vendors: an SLO should reflect what users need, not what a provider promises.
- No policy consequences: a budget that never changes release behavior is only a dashboard.
- Dependency blame: failures in shared dependencies still consume the budget of the user-facing service.
- Calendar resets: a calendar-month window lets a service fail heavily on the last day and start fresh; a rolling window avoids this.
A practical starting point is few SLOs per service, measured as close to the user as possible, with targets reviewed every quarter as real data accumulates.
The short version
No online service works perfectly all the time, and trying to reach perfection makes progress slow and expensive. An error budget accepts this openly. The team agrees on how much failure users will tolerate, for example a few minutes of problems per month.
That allowance works like a monthly spending budget. While money is left, the team can take some risks and release new features. When the budget is spent, the priority switches to making the service stable again.
Where it makes a difference
A payments team runs a checkout API with an SLO of 99.95 percent successful requests over a rolling 28 days. The service handles about 20 million requests in that window, which gives an error budget of roughly 10,000 failed requests.
Midway through the window, a configuration change causes a burst of errors and consumes 60 percent of the budget in two hours. The fast burn-rate alert pages the on-call engineer, who rolls back the change. Under the agreed policy, the remaining budget below 50 percent means smaller releases and longer canary phases for the rest of the window.
The product manager and engineers do not argue about whether to keep shipping, because the policy already decided it. The team spends two weeks on automated configuration validation, and over the following windows budget consumption drops and the normal release cadence returns.