Error budget

What is an error budget?

An error budget is the amount of unreliability a service is allowed to incur within an SLO window. It is the gap between perfect availability and the reliability target, and SRE teams treat it as a finite resource that funds calculated risk-taking, from faster releases to controlled experiments.

Also called the reliability budget.

Why error budgets matter

Engineering and operations teams have long argued about the same question: ship faster, or protect stability? Without a shared metric, the argument is unwinnable. Product wants velocity, ops wants quiet pagers, and leadership picks whichever side complained most recently.

The error budget turns that argument into math. If the SLO says 99.9% availability over 30 days, the service can be unavailable for 43.2 minutes during that window before customers experience service worse than the promised level. As long as the budget has room, the team can deploy aggressively, run chaos experiments, and accept the small risk of a regression. When the budget is gone, the team slows down and invests in reliability.

This framing aligns SREs, developers, product managers, and incident management leaders around a single number. It replaces opinion with evidence and gives ITOps and AIOps platforms a clear metric to optimize against: every minute of saved downtime is a minute the team can spend on shipping value.

How error budgets work

An error budget is derived directly from the SLO. The mechanics are simple:

Pick an SLI: Choose a measurable indicator of service health, such as the fraction of successful requests or the fraction of requests served within a latency threshold.
Set an SLO: Define the target value of that SLI over a rolling window, such as 99.9% over 30 days.
Calculate the budget: Subtract the SLO from 100%. A 99.9% target leaves a 0.1 % error budget, which over 30 days equals 43.2 minutes of allowed downtime or failed requests.
Track burn rate: Monitor how quickly the budget is being consumed. A fast burn early in the window is a stronger warning signal than a slow, steady consumption.
Apply policy: Tie team behavior to budget health. A healthy budget unlocks faster deployments and experiments. Exhausted budget triggers a freeze on risky changes until the service recovers.

Worked example: 99.9% over 30 days

A 99.9% availability SLO over a 30-day window allows 0.1% of total time as downtime.

Thirty days is 43,200 minutes. 0.1 % of 43,200 is 43.2 minutes. That’s the entire monthly error budget.

Different SLO levels produce sharply different budgets:

SLO	Allowed downtime per 30 days	Allowed downtime per year
99%	7 hours 12 minutes	3 days 15 hours
99.5%	3 hours 36 minutes	1 day 19 hours
99.9%	43.2 minutes	8 hours 45 minutes
99.95%	21.6 minutes	4 hours 22 minutes
99.99%	4.32 minutes	52.6 minutes

The exponential cost of additional nines is why SRE teams deliberately set reliability targets. Chasing 99.999% is dramatically more expensive than 99.9%, and most services do not need it.

Healthy vs. exhausted error budgets

The most useful part of the error budget framework is how it changes team behavior. A healthy budget and an exhausted budget should produce visibly different operating rhythms.

Dimension	Healthy error budget	Exhausted error budget
Release cadence	Normal or accelerated	Slowed or frozen for risky changes
Risky experiments	Encouraged within reason	Paused
Engineering focus	Feature work, platform improvements	Reliability fixes, postmortem actions
On-call posture	Standard rotation	Heightened readiness, possible incident commander rotation
Stakeholder conversation	Velocity and roadmap	Reliability investment and customer impact

Punishment isn’t the point. A blown error budget is information. It says the service is consuming reliability faster than the business committed to, and that behavior should be adjusted until the balance returns.

Error budget use cases in IT operations

Error budgets are not just an SRE artifact. They show up across the broader ITOps and incident management practice:

Release velocity decisions: Deploy pipelines, check error budget health, and gate risky releases when the budget is low.
Feature vs. reliability prioritization: Product managers and engineering leads use budget burn to weigh new features against reliability investments.
Change risk management: Change advisory boards consult error budget status when scheduling significant changes, often in combination with AIOps change risk scoring.
Major incident triage: Incident commanders factor remaining budget into urgency and resourcing decisions during long-running incidents.
Executive reporting: Error budget burn trends give leaders a single, honest view of service health across a portfolio.

Common misconceptions about error budgets

The budget is a target to spend: The budget caps allowable unreliability; it’s not a quota to consume. A service that uses zero budget is fine, although it may suggest the SLO is set too low.
Error budgets only apply to availability: Any SLI can have an error budget, including latency, correctness, and freshness. The math is the same.
Burning the budget means punishment: It means adjusting behavior. Slowing risky changes and investing in reliability is the system working as designed.

Frequently asked questions about error budget

How do you calculate an error budget?

Subtract the SLO from 100% and apply that fraction to the SLO window. A 99.9% SLO over 30 days leaves a 0.1% error budget, which equals 43.2 minutes of allowed downtime in that window.

What happens when an error budget is exhausted?

Most SRE teams freeze risky changes and shift engineering focus to reliability work, postmortem actions, and platform improvements until the service recovers. The freeze is a policy choice agreed in advance, not a reaction to a single bad day.

What is the difference between SLA, SLO, and error budget?

An SLA is a contractual commitment to customers. An SLO is an internal target, usually stricter than the SLA. The error budget is the amount of unreliability the SLO allows, expressed as time, requests, or percentage of the SLO window.

Should error budgets reset every window?

Most teams use a rolling window, often 28 or 30 days, so the budget continuously recalculates rather than resetting on a fixed calendar date. This avoids end-of-month gaming and gives a more accurate picture of recent reliability.

What is error budget burn rate?

Burn rate is the rate at which the budget is consumed relative to the window. A burn rate of 1.0 means the budget is consumed at exactly the rate that would exhaust it over the SLO window. High burn rates, such as 10x for an hour, are common alerting triggers because they predict imminent budget exhaustion.