What is an error budget?
Engineering culture and software practice
An error budget, a concept from Google's 2016 SRE book, is the amount of unreliability a service is allowed over a period, calculated as one hundred percent minus its reliability target. While budget remains, the team may ship changes and take risks; once it is spent, reliability work takes priority over new features. It turns the vague question of how reliable something should be into a shared, numeric decision rule that both engineers and product owners agree to follow.
What this means
Perfect reliability is impossible and, past a point, not even desirable, because every extra fraction of a percent costs far more than the last and slows everything down. So instead of demanding that nothing ever breaks, an error budget states plainly how much breakage is acceptable. If the target is 99.9 percent reliable, the budget is the remaining 0.1 percent: the permitted amount of failure for the month.
The clever part is what the budget is for. It is not a punishment; it is a spending allowance. As long as there is budget left, the team can take risks, push releases quickly and try things, because a bit of failure is affordable. When the budget runs out, the rule flips: no more risky changes until reliability is restored. The number, agreed in advance, decides the argument that would otherwise be settled by whoever shouts loudest.
The idea comes with a small vocabulary. An indicator is what you measure, an objective is the target you set for it, and an agreement is the contract with a customer that carries consequences. The error budget falls out of the objective automatically once you have chosen it.
Why it matters
Every organisation that runs software lives with a standing tension between shipping new things and keeping the existing thing stable. Product people are rewarded for speed; the people responsible for reliability are rewarded for stability; and left to personalities, the balance is decided by negotiation rather than evidence. The error budget replaces that with a single agreed metric, which the Google book describes as removing the politics from the negotiation because everyone shares responsibility for the number.
It also forces an honest conversation about how reliable a service actually needs to be. A target of 99.9 percent sounds abstract until you translate it: over a thirty-day month it permits roughly forty-three minutes of downtime. Seeing the real allowance often changes minds in both directions, revealing either that a cherished target is unaffordable or that a service is being held to a standard far higher than its users need.
For a small firm the value is not the arithmetic but the framing. Deciding in advance what level of disruption is acceptable, and agreeing what happens when that level is breached, prevents the familiar pattern where every incident becomes a fresh crisis and every release a fresh fight. It converts reliability from a feeling into a policy.
The same thinking is now being extended, carefully, to AI services. Some teams run what amounts to a quality budget for a model, setting a tolerable rate of wrong or unacceptable answers and treating a breach as a trigger to stop and fix rather than keep shipping. This is a sensible adaptation of the idea, but it depends entirely on being able to measure wrong-answer rates reliably, which is much harder than measuring whether a web request succeeded, so it should be described as an emerging practice rather than a settled one.
How it works
Where the term came from
The error budget was set out in the 2016 O'Reilly book Site Reliability Engineering: How Google Runs Production Systems, principally in the chapter "Embracing Risk" by Marc Alvidrez, with the surrounding vocabulary defined in the "Service Level Objectives" chapter. The book argues that because product development is measured on velocity and reliability engineering on stability, a shared, objective metric is needed to settle how much risk to allow, and that metric is the error budget. The 2018 companion, The Site Reliability Workbook, added detailed guidance on error-budget policies and on turning objectives into alerts, and included an example error-budget policy as an appendix. The concept has since spread widely through DevOps and platform teams well beyond Google.
Indicators, objectives and agreements
The three terms are worth separating. A service level indicator is the actual measurement, such as the proportion of requests served successfully. A service level objective is the target you set for that indicator over a period, such as 99.9 percent successful over thirty days. A service level agreement is a contract with a customer that attaches consequences, typically financial, to meeting or missing a level. The book's memorable test is to ask what happens if the target is missed: if there is an explicit consequence, it is an agreement; if not, it is an objective. Reliability engineers usually help define indicators and defend objectives but stay out of the commercial agreement.
Computing the budget and writing the policy
The budget is simply one hundred percent minus the objective, applied over the chosen window. A 99.9 percent monthly objective yields a 0.1 percent budget, about forty-three minutes. Every outage, and even planned maintenance that affects users, draws it down. The essential companion is the policy: a written statement, agreed before anything breaks, of what the organisation will do when the budget is exhausted, typically freezing risky releases and diverting effort to reliability until the budget recovers. A budget with no policy behind it changes nothing.
How experienced teams use it
Mature teams alert on the rate at which the budget is being burned rather than waiting for it to run dry, so they can act before customers are badly affected; the workbook recommends multi-window, multi-burn-rate alerting for this. They also revisit their objectives, because a target that is never breached may be too strict and one that is always breached may be meaningless or measured against the wrong indicator.
Examples
An online retailer with an eight-person engineering team argues constantly about releases: marketing wants frequent changes, the on-call engineers want fewer. They agree an objective of 99.9 percent successful checkouts per month and a policy that if the budget is spent, non-essential releases pause until the next month. Within a quarter the fights stop, because the decision is now made by the number rather than by whoever is most senior in the room.
A council department runs an online form for residents. It sets a modest objective, 99.5 percent availability, recognising that the service is important but not life-critical and that chasing higher numbers would cost money it does not have. Translating the target shows it permits a few hours of downtime a month, which comfortably covers overnight maintenance. The explicit budget lets the team schedule updates without guilt or panic.
A charity deploys an AI chatbot to answer benefits questions and worries about wrong answers. It defines a quality budget: no more than a set percentage of sampled answers may be materially incorrect in a month, checked by a caseworker against a rubric. When a model update pushes the error rate over the line, the policy stops further changes until the problem is understood. The charity is careful to treat the measurement as approximate, because judging answer quality is far less clear-cut than counting failed requests.
Common misunderstandings
The first misconception is that the aim is to spend the whole budget. It is not; the budget is a ceiling on acceptable failure, not a quota to use up. A month that comes in well under budget is a good month, not wasted headroom, though a service that never uses any budget may have set its target too high.
The second is that a hundred percent reliability is the ideal target. The book argues the opposite: a hundred percent is almost always the wrong target because the cost of the last increment is enormous and users cannot tell the difference above a certain point. A budget of zero also makes every change forbidden, which is unworkable.
The third is that an error budget is a form of technical debt or a risk register. It is neither. Technical debt is accumulated design cost; a risk register is a catalogue of identified risks and mitigations. An error budget is a live release-governance rule: it decides, right now, whether the team may ship. Unlike a change-control process it does not approve individual changes; rather, it sets the condition under which changes are allowed at all, and it could feed into change control rather than replace it.
The fourth is that the indicator does not matter much. It matters enormously. A budget measured against the wrong indicator, one that does not reflect what users actually experience, gives false confidence, and an indicator that is easy to game invites teams to hit the number without improving the service.
Risks and boundaries
The commonest failure is a budget nobody enforces. If the policy says releases pause when the budget is spent but the organisation overrides it every time a deadline looms, the budget is theatre. Its entire power comes from being agreed in advance and honoured under pressure.
A second boundary is indicator quality. The arithmetic is trivial; choosing what to measure is the hard part. Availability of a back-end component may look healthy while users are suffering, so the indicator has to track the experience that matters. Targets can also be gamed: a team can technically meet an objective while degrading the parts of the service that are not measured.
The extension to AI is the liveliest debate. Applying budget thinking to wrong-answer rates is appealing, but reliability of a web request is binary and cheap to measure, whereas the quality of a generated answer is a judgement that needs sampling, rubrics and human review. Quality budgets for AI can be useful discipline, but they rest on measurement that is genuinely difficult, and presenting them as equivalent to a classic availability budget overstates how solid the number is. Treat them as an emerging practice, and be honest about the error bars on the error budget.
What to do next
Pick one important service and ask what level of failure is genuinely acceptable to its users over a month, then translate the target into real minutes or real failed transactions so everyone sees what it means. The translation is where the useful conversation happens.
Write the policy before you need it. Agree, in advance and in writing, what the organisation will do when the budget is spent: which releases pause, whose effort shifts to reliability, and who can authorise an exception. A budget without a policy is just a statistic.
Choose indicators that reflect the user's experience, not the health of an internal component, and sanity-check that they cannot be trivially gamed. If you can only measure one thing well, measure whether the thing the customer came to do actually worked.
If you are applying the idea to an AI service, define the quality measure and the sampling method explicitly, keep a human in the review, and be candid internally that the wrong-answer rate is an estimate. Do not treat an AI quality budget as if it were as precise as an availability budget.
FAQs
How do I calculate an error budget?
Subtract your reliability target from one hundred percent and apply it over your chosen period. A 99.9 percent monthly target gives a 0.1 percent budget, roughly forty-three minutes of allowed downtime.
What is the difference between an SLI, an SLO and an SLA?
The indicator is what you measure, the objective is the target you set for it, and the agreement is the customer contract with consequences. The quick test: if missing the target has an explicit penalty, it is an agreement.
What happens when the budget runs out?
Your policy takes over, typically pausing risky releases and shifting effort to reliability until the budget recovers. The policy must be agreed before it is needed.
Is the goal to use up the whole budget?
No. The budget is a ceiling on acceptable failure, not a quota. Coming in under it is good, though never using any may mean your target is set too high.
Why not aim for one hundred percent reliability?
Because the last increments cost enormously more than the earlier ones, users cannot perceive the difference above a point, and a zero budget forbids all change.
Can this apply to an AI service?
Some teams run a quality budget capping wrong-answer rates, treating a breach as a stop signal. It is a reasonable adaptation but depends on measurement that is much harder than counting failed requests.
Is an error budget the same as change control?
No. It sets the condition under which changes are allowed at all rather than approving individual changes, and it can feed a change-control process rather than replace it.