What Is an Error Budget? (SRE Explained)

The idea comes straight from Google's Site Reliability Engineering practice. In Embracing Risk, the SRE Book defines the error budget as the flip side of the Service Level Objective: if you commit to a 99.9% SLO, you are simultaneously committing to tolerate 0.1% unreliability — and that 0.1% is not failure, it is allowance. The mental shift is everything. Reliability stops being an absolute demand ('never go down') and becomes a finite resource with a balance you can watch, spend, and run out of.

That reframing dissolves a fight that every engineering org has had. Product wants to ship; operations wants stability; nobody can say how much reliability is 'enough,' so the argument recurs at every launch. The error budget answers the question numerically once, in advance, and then lets the data referee. As Atlassian's breakdown of SLA vs. SLO vs. SLI puts it, the objective is the internal promise and the budget is what you have left to gamble against it.

The budget is derived, not invented. It falls out of three nested terms — the SLI, the SLO, and the budget — which we cover in full in SLA vs. SLO vs. SLI. The SLI (Service Level Indicator) is the thing you actually measure: the ratio of good events to total events, such as successful HTTP responses over all responses. The SLO is the target you hold that indicator to — 99.9%. The error budget is simply everything the SLO leaves on the table: 100% − SLO, measured over a fixed window, usually 28 or 30 days.

Percentages are abstract, so translate them into units people feel. Over a 30-day month, a 99.9% availability SLO buys about 43 minutes of allowed downtime; 99.95% cuts that to roughly 22 minutes; 99.99% to about 4 minutes. For a request-based SLO the same math gives you a count instead of a clock: 0.1% of 10 million requests is 10,000 permitted failures before the budget is gone. Google's Implementing SLOs chapter walks through choosing the right SLI and window so the budget reflects what users actually experience rather than an arbitrary uptime number.

The budget is consumed by every deviation from the SLO: an outage, a spike of failed requests, elevated latency past your threshold, a botched deploy. Each incident draws the balance down. When the window rolls over — a new 30-day period begins — the budget refills. That rolling replenishment is what makes it a live resource rather than a one-time allotment: you are always spending against the trailing window.

This is the argument the SRE Book's chapter on Service Level Objectives makes at length. The cost curve of reliability is not linear — it bends sharply upward as you approach 100%. Getting from 99% to 99.9% might be a caching layer and a retry policy; getting from 99.99% to 99.999% can mean multi-region failover, chaos testing, and a release cadence slow enough to vet every change. Past a point you are spending enormous effort buying nines that sit below the noise floor of the user's own connection. So the SRE move is to set the SLO deliberately below 100% and then, crucially, to treat the leftover unreliability not as a shameful gap but as a budget you are expected to spend. Unspent budget is a signal you are being too conservative — you could be shipping faster.

The budget's real job is to align two teams that otherwise pull in opposite directions. Developers are rewarded for shipping features; operators are rewarded for keeping things up. Left unmediated, those incentives collide at every release. The error budget replaces the collision with a shared scoreboard: while budget remains, ship features fast — take the risk, launch the experiment, roll out quickly, because the numbers say you can afford it. When the budget is exhausted, stop shipping risky changes and redirect effort to reliability: fix the bugs, harden the fragile paths, pay down whatever has been burning the budget.

Notice what this does to the conversation. Nobody has to argue for slowing down; the balance decides. Product and ops are no longer adversaries negotiating gut feelings — they are reading the same meter. Reliability work gets prioritized automatically at exactly the moment the data says it is needed, and velocity is protected at exactly the moment the data says it is safe. A tight mean time to recovery also helps here: faster incident resolution means each outage spends less of the budget, which buys back room to keep shipping.

A budget without a rule is just a chart. The error budget policy is the pre-agreed, written contract for what happens when the budget runs out — decided before an incident, not litigated during one. A common policy: while budget remains, launches proceed through the normal release readiness checklist; once the budget is spent, a feature freeze kicks in and the team's priority shifts to reliability until the next window restores the balance. Some policies escalate by severity, tying the freeze to how the budget was burned — a single SEV1 or SEV2 can consume a month of budget in one afternoon and trigger the policy on its own.

The power of writing it down in advance is that it removes the emotion and the politics from the decision. When the budget is gone, the freeze is not a punishment somebody chose to impose — it is a rule everyone signed off on when things were calm. That is what converts a perpetual argument about 'how much reliability' into a single data-driven trigger.

So the failure modes are not subtle. A budget with a bad SLI behind it produces confident, precise, wrong answers. A budget with a solid SLI but no enforcement is a dashboard people glance at and ignore. Both are worse than no budget, because they wear the costume of rigor without the substance. The prerequisite for the whole model is that you can measure user-facing reliability well and that the org has agreed, in advance, to be governed by the number.

Every user-facing bug spends error budget. A failed checkout, a broken form, a page that errors on load — each is a draw against the balance, whether or not it ever pages an on-call engineer. Which means the fastest way to protect the budget is to make the biggest budget-burners visible and faster to fix. That is the narrow thing BugMojo does: its browser extension captures each user-facing failure with the state around it — an rrweb session replay, the console output, and the network request that failed — so the bug arrives as a reproduction instead of a vague report. Reproductions are what shrink the time from 'budget is bleeding' to 'change merged,' which is exactly the loop the error budget is meant to keep tight. BugMojo is capture-and-repro, not an SLO monitor — but the reproductions it produces are what let you spend less budget recovering from the bugs that eat it.