Skip to main content

Calculate burn from the actual request population

What This Concept Is​

Burn rate compares observed bad-event fraction with the allowed bad-event fraction. For target S, burn is (bad/total)/(1-S). It is dimensionless. A rate of two means the observed bad fraction is twice the allowance, not that two requests failed.

Why It Matters Here​

Module 01 separated offered, admitted and completed work. The reliability SLI must say which population it includes, including rejected or timed-out requests when they belong to the user-visible promise. Otherwise overload can appear healthy precisely because the worst experiences disappeared from the denominator.

Concrete Example​

For a 99% teaching target, a window with 2 bad requests out of 100 has burn 2. Combine (10 total,1 bad) and (100 total,1 bad): the result is 2/110 bad, about 1.82 burn. Averaging 10% and 1% yields 5.5%, or 5.5 burn, which incorrectly gives the small bucket equal weight.

Compute numerator and denominator over the same population and boundary. A request may be bad for availability or latency under your contract; define whether the combined SLI counts it once. Never sum overlapping failure categories as if they were distinct requests.

Common Confusion / Misconception​

A burn ratio is not the remaining monthly error budget. Projecting exhaustion time assumes a future traffic pattern and a budget period; request-based budgets are especially sensitive to varying volume. A 100% target leaves zero allowance and makes this burn definition undefined, so the lab rejects it.

How To Use It​

Freeze the SLI eligibility, good/bad predicate, window boundary and target. Aggregate counts before dividing. Keep exact fractions for threshold checks, and retain the raw counts in the alert evidence. Separate a teaching threshold from a service policy justified by business needs and response capacity.

Check Yourself​

Why is averaging bucket percentages wrong here? What happens when no eligible requests occur? Is a high burn rate evidence of the cause of failure? Which rejected requests belong in your SLI?

Mini Drill or Application​

Hand-calculate three unequal-volume windows. Compare pooled counts with an average of percentages and explain the discrepancy. Use actual request observations from the original SLI lab to verify eligibility and deduplication of overlapping failure categories.

Read This Only If Stuck​

Fundamentals of Software Architecture — measurable quality attributes. Google SRE: Alerting on SLOs provides the burn-rate foundation; the lab's chosen thresholds are illustrative.