Error-budget calculations, balances and burn rates

“We still have budget” can settle a release argument surprisingly quickly. Before it does, ask what is left and what it is left for. An error budget turns a reliability target into a countable allowance, such as one bad request in a thousand. The calculation is useful because the team can reproduce it; the release decision still depends on what that allowance measures and what the agreed policy says.

At a 99.9% request-success target, one million eligible requests allow 1,000 bad requests. After 600 bad requests, 400 remain in that window's calculation. The arithmetic is straightforward. Interpreting the 400 as permission for the next release takes an additional step: deciding which risks the number describes and what the agreed policy allows.

The measured behavior is the service-level indicator, or SLI; its target and window form the service-level objective, or SLO. For an objective expressed as a fraction of good events, the allowed bad fraction is one minus the target. An error budget applies that fraction to the eligible population, so its meaning begins with what counts as an event and what makes one bad.

Requests and minutes are different budget units

For the request example, 99.9% success leaves 0.1%, or 0.001, as the permitted bad fraction. Multiplying one million requests by 0.001 yields 1,000 bad requests, and subtracting 600 gives 400. Every number refers to the same eligibility rule and window. The remainder is a request count, not a duration or a forecast.

Another way to read the example is that 60% of the allowance has been spent: 600 divided by 1,000. The remaining 40% describes this measured window. It does not promise forty more minutes of operation or tell you how many requests the next release will affect. Those questions require traffic and failure assumptions beyond the balance itself.

A time-based objective starts with a different population. Exactly thirty days contain 43,200 minutes; 0.1% of that is 43.2 minutes classified as bad under the indicator's definition. This does not make 43.2 minutes interchangeable with 1,000 failed requests. A minute of peak demand can contain far more requests than a quiet minute.

A budget belongs to its own indicator and window. Unused allowance for one experience cannot be transferred to an unrelated experience or used to dismiss another objective's failure. A positive balance is meaningful evidence about the defined outcome, not a general measure of how much harm the service can afford.

A rolling window has a moving edge. Old events can leave it while new ones arrive, so a better balance does not necessarily mean somebody repaired the service. Put the SLI, window and calculation time beside the report. Those details let the next reader distinguish a change in behavior from a change in which events the report contains.

For an illustrative report, suppose the population is still one million eligible requests, but the outcome collector lost records for part of the window. The earlier figure of 400 remaining is then a balance from the available evidence, not a verified allowance for the whole population. Keep the missing interval and affected population with the report, and apply the agreed missing-telemetry policy before using it to approve a release. The completeness lab shows why an observed zero and an unavailable observation cannot support the same conclusion.

Remaining budget is a count in a defined window

Read diagram description

Illustrative request-based objective: 99.9% of one million eligible requests allows 1,000 bad requests. After 600 bad requests, 400 remain. This is not a conversion to downtime minutes or a prediction of time to exhaustion.

A 1% error rate means 10× burn against a 0.1% allowance

Burn rate divides the observed bad-event fraction by the allowed bad fraction. If the allowance is 0.1% and the observed error fraction is 1%, the ratio is ten. During that observation period, the service is consuming allowance at ten times the pace compatible with the target.

The ratio does not establish how long that behavior will persist. A brief spike and a sustained regression can produce a similar observed rate while needing different responses. Read the observation window, request volume and persistence with the number. Google’s SLO alerting chapter develops the use of multiple windows to make these alerts useful.

For a request-based budget, equal burn rates can spend different amounts of the full-window allowance. In an illustrative completed window of one million requests, the 99.9% target permits 1,000 failures. An hour with 10,000 requests and 100 failures has a 1% error fraction, 10× burn and 10% of that window’s budget consumed. An hour with 1,000 requests and ten failures has the same error fraction and burn rate, but consumes 1% of the budget. Consumption follows failed-event counts; the ratio describes the error fraction relative to the target. A projection based on elapsed time additionally assumes that request volume and the error fraction persist as expected. Retain those assumptions when estimating exhaustion, especially across quiet and peak periods.

Balance and pace can now inform a reliability decision, but they still do not describe every consequence of a proposed change. Consider a hypothetical migration with uncertain rollback on a service that has budget remaining. The request-success balance cannot establish that a data change is recoverable. Its own preconditions and authorization still need to be satisfied.

The release policy supplies the consequence

The release policy specifies how high consumption or exhaustion affects feature releases and reliability work, including who can grant an exception and why. For the migration, it answers the release question raised by the balance; the separate compatibility assessment answers whether the proposed recovery remains possible. Both results belong in the decision because they describe different consequences of proceeding.

Exhaustion does not require stopping every change indiscriminately. A repair intended to restore reliability has a different purpose from an unrelated feature release. The policy guide and calculation template help make that distinction and its supporting calculation explicit.

For the migration, the team can now ask two properly separated questions: what does the current budget imply under the release policy, and has the migration's recovery risk been addressed by the right authority? A healthy answer to one does not supply the answer to the other.

The report should leave the release discussion with its identity intact: this indicator, this window, this calculation time and this policy consequence. Those details explain what “budget remaining” means. If the product changes the experience being measured, revisit the objective as well. Precisely counting the wrong outcome would make the argument tidier without making the decision better.