SLO burn rate: when should this alert clear?

Exact window evidence

Count bad requests before calculating burn

Each row is one synthetic minute with a request count and an error count. The lab sums errors and requests inside each rolling window, divides those totals, then divides the observed error fraction by the fraction allowed by the selected SLO. It does not average minute percentages. A high-error minute carrying ten requests should not weigh as much as one carrying a thousand. Sixty earlier baseline minutes warm the windows before the displayed period starts at minute zero. They influence early rolling rates but are not charged to the new period’s consumed-budget counter.

Set traffic and the incident

SLO chooses a success target from ninety through 99.99 percent. Baseline requests/minute and Incident requests/minute choose separate integer traffic rates, including zero. Baseline error rate and Incident error rate are percentages in increments of 0.01 percentage points. Incident start sets its first minute and Incident duration sets the number of consecutive incident minutes; zero disables the incident. Outside that interval, the baseline rate and error fraction apply. Expected fractional errors are accumulated as a deterministic remainder and converted into whole errors, avoiding random changes between replays. These are generated counts, not imported monitoring data.

Choose the windows and policy

Long window selects five through sixty minutes; Short window selects one through five. Compare alert policy chooses both windows, long only or short only. Both means each observed burn rate must meet the same threshold. A missing denominator is unknown, not a successful zero-error sample. Period days and Budget spend trigger derive the threshold as trigger fraction multiplied by period minutes divided by long-window minutes. At thirty days, a two-percent trigger and a sixty-minute long window, the threshold is 14.4. The policy is a single teaching alert pair, not a complete production paging and ticketing policy.

Follow the default incident and recovery

Restore defaults: 99.90 percent SLO, one thousand requests per minute on both traffic settings, zero baseline errors, five-percent incident errors, start ten and duration twenty. Each incident minute contributes fifty errors. The five-minute burn rises quickly; the sixty-minute burn reaches fifteen at minute twenty-seven, so the combined alert starts there. The incident stops after minute twenty-nine. At minute thirty-three the short window contains only one incident minute and its burn has fallen to ten; the combined alert clears even though the long window still carries substantial incident history. Switch to long-only policy to see that stale alert remain open.

Separate a spike from sustained loss

Set duration to one minute while retaining the defaults. The short-window burn peaks at ten and neither window reaches the threshold. With duration two, short-only policy fires but both-window policy does not. Change Incident requests/minute to ten and keep baseline traffic at one thousand: verify the rolling denominators and error counts rather than expecting equal weight for each minute. Set both traffic rates to zero. The cards show no observations and the alert is unknown; no fake healthy state or division-by-zero value is displayed. Turn errors to one hundred percent and reduce the projected period to one day to inspect overspend.

Understand the budget projection

Projected period requests equals baseline requests per minute multiplied by period minutes. The allowed error count is that projection multiplied by one minus the SLO. The remaining count subtracts errors observed since minute zero, and the percentage can become negative instead of concealing overspend. This is a fixed planning projection, not the final measured budget of a real rolling SLO period. If incident traffic differs from baseline, the projection does not silently revise itself. At the default horizon, one thousand incident errors consume about 2.315 percent of the projected 43,200-error budget. Actual request-based period compliance requires the real full-period denominator.

Inspect without changing the calculation

Play maps minutes zero through one hundred twenty onto sixty inspection seconds. Pause holds the selected minute; Next minute advances one; Restart rewinds. Speed adjusts viewing pace, Inspect time scrubs and Show final result reveals the horizon. Every input edit rebuilds and pauses the deterministic trace. Restore defaults restores all controls. The chart plots both computed rolling burn rates against the derived threshold; cards expose numerator, denominator, alert state and projected remaining budget. Open the exact evidence to see the current minute and window boundaries. No monitoring backend, missing telemetry policy, alert suppression, latency SLI, notification routing or production incident response is implemented.

Alerting reference: Google SRE Workbook: Alerting on SLOs.