What is an error budget?

An error budget is the amount of allowed unreliability — like a small percentage of failed requests or minutes of downtime — that a service can accumulate while still meeting its SLO. It's used to decide how much release risk a team can safely take on.

How is an error budget calculated?

It's simply 100% minus the SLO target over the same measurement window. A 99.9% availability SLO over 30 days leaves an error budget of about 43 minutes of downtime for that period.

What happens when an error budget runs out?

Common practice is a release freeze: teams stop shipping new risky changes and redirect effort to stability work — root-causing recent incidents and hardening the system — until the budget recovers.

Who enforces error budget policy?

It varies by organization, but it's typically a jointly agreed policy between engineering and product leadership, sometimes formalized so it isn't overridden under feature-delivery pressure.

Does a fresh error budget reset every month?

It depends on the measurement window chosen. Many teams use a rolling window, like the trailing 30 days, so the budget continuously recovers as old incidents age out rather than resetting on a fixed calendar date.

Why not just aim to never use the error budget?

An unused error budget usually means the team is being overly conservative and could be shipping value faster; the budget exists specifically to make some calculated risk-taking a deliberate, sanctioned choice.

DevOps

Error Budget

IntermediateConcept5.2K learners

An error budget is the quantified amount of unreliability a service is allowed to have while still meeting its Service Level Objective, used to balance the pace of shipping new changes against the need for stability.

#ErrorBudget #DevOps#Concept#Intermediate#ServiceLevelObjective #ServiceLevelAgreement #SiteReliabilityEngineering #ChaosEngineering #SoftwareDelivery#Glossary#SkillVeris

Definition

An error budget is the quantified amount of unreliability a service is allowed to have while still meeting its Service Level Objective, used to balance the pace of shipping new changes against the need for stability.

Overview

If a service has a Service Level Objective (SLO) of 99.9% availability, its error budget is the remaining 0.1% — roughly 43 minutes of allowed downtime per month. That budget can be 'spent' on anything that carries risk: rolling out a new feature, running a chaos engineering experiment, or performing planned maintenance. Framing reliability this way turns an abstract tradeoff — 'should we ship this risky change?' — into a concrete, numeric decision. Error budgets are the central mechanism that makes site reliability engineering (SRE) work as a governance model rather than just a set of good intentions. When a service has budget remaining, teams are free to move fast and take calculated risks. When the budget is exhausted, the common convention is a release freeze: new risky changes pause, and the team's priority shifts entirely to stability work — fixing root causes, improving observability, and closing gaps found during recent incident management reviews — until the budget recovers. Because the budget is tied directly to the SLO, and the SLO is normally set stricter than any external Service Level Agreement (SLA), a team burning through its error budget gets an early warning long before customers are likely to notice a real problem, giving them time to course-correct.

Key Concepts

Directly derived from the gap between 100% reliability and the SLO target
Provides a shared, numeric language for the tradeoff between velocity and stability
Spent on any risky activity — deploys, migrations, experiments, planned maintenance
Exhaustion typically triggers a release freeze and a pivot to stability work
Tracked on rolling windows (e.g., trailing 30 days) so it recovers over time
Makes reliability a shared, cross-team responsibility rather than solely operations' job

Use Cases

Deciding whether to approve or delay a risky production deployment

Triggering an automatic freeze on new releases when reliability degrades

Justifying investment in stability and automation work to product stakeholders

Setting the cadence and blast radius for chaos engineering experiments

Aligning engineering and product teams around a single, shared reliability metric

Frequently Asked Questions

From the Blog

Programming

Python Error Handling: try, except, finally Made Simple

A comprehensive guide to python error handling: try, except, finally made simple — written for learners at every level.

Python Error Handling: try, except, finally Explained

Errors are inevitable; crashes are not. This guide explains Python's exception system from first principles: how try/except/finally works, which exceptions to catch (and which to let propagate), how to raise your own exceptions, and how to write error handling that helps debugging rather than hiding bugs.