Burn rate needs the same eligible-event denominator as the SLO

For a request-based objective, define the eligible population, the criterion for a good result, and the measurement window. Bad events can include latency violations as well as explicit errors when the SLI defines them that way. Excluded traffic, missing telemetry, retries, and partially observed requests can change the denominator. An infrastructure health ratio is not automatically the same as user-request success. Keep the objective's event definition consistent across dashboards, budget calculations, and alerts so one graph does not appear healthier merely because it filters out failed attempts.

Let ε be the allowed bad fraction and r the observed bad fraction over an alert window. Burn b=r/ε is dimensionless; b=1 spends budget at the objective's allowed fraction of traffic. It is not itself a probability and can exceed one. A tiny denominator can make a single failure produce a large noisy ratio, while no eligible events makes the ordinary fraction undefined. Specify missing-data and low-traffic policy rather than silently treating no observations as perfect service or dividing by zero.

The fraction of a fixed request budget spent in one window is its bad-event count divided by the allowed period count. Expressing this as burn times the window's share of period requests is exact under matching definitions. Replacing that traffic share with window-duration divided by period-duration requires constant eligible traffic or another explicit approximation. Large incidents often change traffic because users retry, abandon requests, or encounter front-door failures. A forecast based on yesterday's rate can therefore be wrong precisely when the budget matters most.

A fixed-period request budget whose final population is not yet known needs an explicit projection or a policy for updating the denominator. A rolling window additionally ages out old good and bad events, so its remaining budget is not a permanently decreasing tank. A time-based availability budget has another denominator and can use duration directly when its SLI is defined that way. Do not switch among these models while keeping the same exhaustion label. State whether a number is observed budget use, a projected final outcome, or a hypothetical exhaustion time under unchanged conditions.

Google's SRE workbook discusses burn-rate alerting across windows to balance detection and reset behavior. A short window can react quickly but be noisy; a longer window can establish sustained spending but retain historical signal after recovery. The exact thresholds should reflect the objective, traffic, and response policy. A cleared short-window ratio is not proof the period budget has recovered. Evaluate alerts with incident traces and low-traffic cases, and keep user-facing budget policy separate from a particular monitoring expression's implementation details.

The probability lab illustrates small-sample variation only. Reset, explicitly set BOTH p=0.01 and n=30, interpret success as a bad event, predict zero bad events with probability 0.99³⁰≈0.7397, then Play or Step. Reset and re-set BOTH p=0.05 and n=30; predict 0.95³⁰≈0.2146. Edits retain t; playback highlights exact independent counts. The lab has no SLO window, rolling budget, telemetry loss, or varying traffic and cannot infer a true production error rate from one count. Its probabilities are illustrative values, not the objective's target.