Error Budget Units: Why Burn Rate Beats Remaining Budget

A target of 99.9% implies that one request in a thousand may fail. That single sentence contains the whole idea of an error budget and also the reason it is usually implemented badly: the budget is a quantity, and quantities have units, and the units determine what can be done with the number. A remaining budget expressed as a percentage of a window is not the same object as a remaining budget expressed as a count of failures, and neither is the same as a rate at which the budget is being spent.

The distinction matters because budgets are used for two incompatible purposes at once. They are accounting devices, answering how much unreliability has been consumed so far, and they are control devices, deciding when to stop changing the system. Accounting wants a stock; control wants a flow. A dashboard that shows only the stock will report a comfortable 60% remaining right up until the moment it reports zero, because a stock carries no information about the derivative that produced it.

The budget as a count, and the arithmetic that follows

For an event-based objective, the budget over a window is

$$\text{budget} = (1 - \text{SLO}) \times \text{valid events in window}$$

At 99.9% over thirty days, the budget is 0.001 of the traffic in that period. At one hundred requests per second, thirty days is 259,200,000 requests and the budget is 259,200 failures. At one request per second it is 2,592 failures. The percentage is identical; the operational meaning is not.

Two consequences follow directly. First, the budget scales with traffic, so a service whose traffic doubles in a month gets twice as many permitted failures without anyone deciding that reliability should be looser. Second, a low-volume service can have a budget so small in absolute terms that the accounting becomes meaningless. A service handling a thousand requests a day at 99.9% has a budget of one failure per day. One retry storm consumes a week of it. The target has not changed, but the thing being managed has.

Time-based objectives convert to a different unit entirely. At 99.9%, thirty days of 43,200 minutes yields 43.2 minutes of permitted unavailability. The conversion between the count form and the time form is exact only for a service that is either fully up or fully down, and only at constant traffic. A partial degradation affecting 10% of requests for ten minutes consumes 100 request-minutes in the count form, which is not ten minutes in the time form, and is not 10% of ten minutes either, unless the traffic during those ten minutes happened to be average.

There is a third form in common use: budget expressed as a fraction of the window, so that “50% of budget remaining” means half the window’s permitted errors are unspent. This is the form that dashboards show and the form that is least useful on its own, because it is dimensionless with respect to time. Fifty percent remaining with three days left in the window is a very different situation from fifty percent remaining with twenty-nine days left.

Burn rate is the budget’s derivative, normalized

Burn rate is defined as the rate of budget consumption relative to the rate that would exactly exhaust the budget over the objective’s window:

$$B = \frac{\text{observed error ratio}}{1 - \text{SLO}}$$

A service meeting its target exactly has $B = 1$ and exhausts its budget in precisely one window. A service failing every request has $B = 1/(1-\text{SLO})$, which is 1000 at 99.9% and 10 at 90%. Time to exhaustion is the window length divided by the burn rate.

The normalization is the point. A burn rate of 2 means the same thing for a 99.9% service and a 99.5% service: the budget will be gone in half a window. Raw error ratios are not comparable across targets, and remaining-budget percentages are not comparable across points in the window, but burn rate is comparable across both. This is why every serious alerting scheme on objectives is expressed in burn rate rather than in error rate.

Burn rate also composes with window length in a way that makes thresholds derivable rather than arbitrary. To alert when a fraction $f$ of the budget would be consumed within a lookback period $t$, the threshold is

$$B \geq \frac{f \cdot W}{t}$$

where $W$ is the objective window. For a thirty-day window, consuming 2% of the budget within one hour requires $B \geq 0.02 \times 720/1 = 14.4$. Consuming 5% within six hours requires $B \geq 0.05 \times 720/6 = 6$. Consuming 10% within three days requires $B \geq 0.1 \times 720/72 = 1$. These three numbers appear in published guidance on objective-based alerting, and they are not magic constants; they are the same formula evaluated at three operating points. Anyone can derive thresholds for their own window and tolerance with the same expression.

Instantaneous burn is noise; windowed burn is lag

A burn rate computed over an instant is useless. Requests are discrete, so at any moment the observed error ratio is either 0 or 1 or some coarse fraction, and the implied burn rate swings between zero and a thousand. The estimator needs a window, and the window length trades responsiveness against stability.

A short window detects a fast, total outage within minutes and also fires on a single burst of failed requests that resolves itself before anyone opens a terminal. A long window ignores transients and takes so long to accumulate evidence that a slow, sustained regression is caught hours after it began. Neither choice is right in isolation, which is why production schemes use two windows simultaneously: a long window to establish that the burn is real, and a short window to confirm it is still happening, with the alert requiring both. The mechanics of that pairing, including why the short window also suppresses alerts that would otherwise fire on already-recovered incidents, are treated in multiwindow burn-rate alerts.

There is a statistical floor underneath all of this. A window containing $n$ requests has a resolution of $1/n$ in the error ratio, so the smallest distinguishable burn rate at 99.9% is roughly $1/(n \times 0.001)$. A one-hour window at ten requests per second holds 36,000 requests and resolves about 0.028 in burn rate, which is fine. The same window at one request per minute holds sixty requests, resolves 16.7, and cannot distinguish a burn rate of 2 from a burn rate of 0. The estimator is not broken; the data is too sparse for the question being asked.

Spending is path-dependent even when the total is not

Two services can end a window with the same remaining budget and be in completely different states. One lost 40% of its budget in a single hour and then ran clean for twenty-nine days. The other lost 40% steadily across the month. The arithmetic treats them as equivalent, and operationally they are not: the first has demonstrated a failure mode it has not yet diagnosed, and the second has demonstrated that its baseline is drifting toward the target.

This is why budget accounting is usually paired with a record of the largest single consumption events, not just the running total. A budget that is spent in one contiguous block is evidence of a specific defect; a budget spent in a long shallow slope is evidence about steady-state capacity or about a threshold that sits too close to typical latency. The two demand different responses, and a remaining-budget gauge cannot distinguish them.

The same asymmetry appears across window boundaries. A rolling window does not reset, so an incident near the end of a window keeps consuming budget into the following days, and recovery is gradual by construction. A calendar window resets at a fixed instant, which produces a discontinuity: a service can be out of budget at 23:59 and fully in budget at 00:01 with no change in behaviour. The consequences of that choice for policy, and the equivalence between window length and target, belong to objective windows and time equivalence.

When the budget is a rate limit rather than a measurement

The final reframing is that a budget is only meaningful if spending it has a consequence. A number that is displayed but never acted on degrades into a vanity metric within a quarter, and the degradation is self-reinforcing: once the budget has been exceeded without any effect, exceeding it again is expected.

The consequence is a policy, and the policy needs to be written before the budget is first exhausted, not during the incident that exhausts it. Freezing changes, requiring additional review, or shifting engineering effort toward reliability are all plausible responses, and all of them are contested when proposed under pressure. The design questions — who can grant an exemption, what counts as a legitimate exception, how a freeze is lifted — are covered in error budget policy enforcement. What matters at the level of units is only that the policy be expressed in the same units as the budget, because a policy written in percentages of a window cannot be evaluated against a burn rate.