error budget
/AIR-er BUJ-it/ · noun · Development · Origin: 2016
Definitions
The acceptable amount of unreliability for a service over a given period, calculated as 1 minus the SLO. A service with a 99.9% availability SLO has a 0.1% error budget — roughly 43 minutes of downtime per month. When the budget is depleted, the team should freeze feature releases and focus on reliability. Error budgets transform reliability from a subjective judgment into a quantitative, shared resource.
In plain English: The amount of downtime or errors your service is allowed before you have to stop launching new features and fix reliability issues instead.
Example: We burned through our entire error budget in the first week of the month, so the team agreed to a feature freeze until we fixed the flaky integration test suite.
Origin Story
Google's brilliant trick for ending the war between devs and ops
The **error budget** concept was developed at Google and published in the *Site Reliability Engineering* book (2016). The idea is simple but transformative: if your SLO is 99.9% uptime, you have a 0.1% error budget -- 43.8 minutes of allowed downtime per month.
Error budgets reframe reliability as a resource to be spent, not a constraint to be maximized. If the budget is unspent, the team is being too cautious -- ship faster and take more risks. If the budget is exhausted, freeze deployments and focus on reliability.
This solved the eternal conflict between product teams (who want to ship fast) and ops teams (who want stability). Both now optimize for the same metric. Error budgets gave SREs a data-driven way to say 'no' to risky launches.
Coined by: Google SRE team
Context: Google, pre-2016 (published in SRE book, 2016)
Fun fact: Google's internal rule: if a service exhausts its error budget, the SRE team can enforce a deployment freeze. This gives SREs real power to push back on product teams, backed by data rather than opinion.