Why architecture matters here
The architecture matters because it changes what a page means. Under raw-threshold alerting, a page says 'the error rate crossed 1%,' which tells the on-call nothing about urgency — 1% might be catastrophic for a payment API and irrelevant for a best-effort batch job. Under burn-rate alerting, a page says 'you are consuming your error budget fourteen times faster than sustainable and will exhaust it in two days,' which is intrinsically urgent and self-explaining. The alert carries its own justification, so the human who receives it already knows why it is worth waking up for and how long they have to act.
It matters because it directly attacks the two failures that make alerting worthless: too many false pages and too many missed incidents. A single sensitive threshold floods the on-call with noise until they mute it; a single insensitive threshold lets slow leaks pass unnoticed until the budget is gone. Multi-window multi-burn-rate alerting resolves the tension structurally rather than by picking a compromise value: the high-burn fast alert has a short time-to-detect for the disasters, while the low-burn slow alert has the patience to notice a 3x leak that would take a week to matter. You get sensitivity and specificity at the same time because they live in different alerts.
It matters because burn rate normalizes across services and SLOs. A burn rate of 14.4 means the same thing — 'two days to exhaustion on a 30-day budget' — whether the service targets 99.9% or 99.99%, because the normalization already divides by the permitted error ratio. That uniformity lets an organization define one alerting policy, one ladder of severities, and reuse it across hundreds of services without re-deriving thresholds each time. The SLO number changes; the burn-rate ladder does not.
Finally, it matters because it ties alerting to a budget that also governs release decisions, so the same signal drives both incident response and engineering priority. When the fast alert pages, you fight a fire; when the slow alert opens a ticket, you have days to fix a chronic reliability issue before it becomes a fire. And when the budget is healthy, the absence of alerts is itself information: it is explicit permission to ship faster and take more risk, because you can see exactly how much margin you have left. Reliability stops being a vague aspiration and becomes a quantity you spend on purpose.
The architecture: every piece explained
Top row: from objective to comparison. Start with the SLO and its budget — say 99.9% success over 30 days, which permits a 0.1% error ratio. A pipeline continuously measures the error ratio as bad events divided by total events over a sliding window. It then computes the burn rate by dividing that observed ratio by the permitted ratio (1 minus the SLO), producing a single dimensionless number: how many times faster than sustainable you are spending budget. Finally it compares to thresholds, and crucially it does this per window — the same burn rate is evaluated over several time horizons at once.
Middle row: the window pairs that make each severity trustworthy. A fast window (often five minutes) catches a sudden spike almost immediately but is noisy — a single bad deploy or a brief dependency wobble can spike it. A slow window (an hour, say) is quiet and confirms that the burn is sustained rather than a transient. The highest severity requires both above 14.4x: the long window proves the incident is real and the short window proves it is still ongoing. Lower severities use lower multipliers (3x to 6x) over longer windows and produce a ticket rather than a page, because a slow leak is urgent over days, not minutes.
Bottom-left: the combining logic. Each severity ANDs its two windows — the alert fires only when the long window is over threshold AND the short window is still hot. The long window gives confidence (no paging on a two-minute blip); the short window gives fast reset (the moment the incident ends, the short window drops below threshold and the alert clears, so you are not stuck acknowledging a stale page long after recovery). This AND-of-windows is the single most important structural trick in the whole design.
Bottom-right and ops: the output and what to tune. A fired alert is enriched with budget context — whether it is a page or a ticket, the current burn rate, and the projected time-to-exhaustion — so the responder starts already oriented. The ops strip names the levers: tune the burn-rate thresholds to hit your target detection time and the fraction of budget you are willing to spend before firing, verify the reset behavior so alerts clear cleanly, and keep the alerting windows aligned to the SLO period so a 30-day objective is not evaluated with windows that quietly assume a different horizon.
End-to-end flow
Follow one incident from a healthy service through a sudden outage to recovery, watching the window pairs fire and clear in order.
Steady state: the service runs at 99.95% success, comfortably inside its 99.9% SLO. The error ratio hovers around 0.05%, so the burn rate sits near 0.5 — spending budget at half the sustainable pace, which means the 30-day budget will actually last longer than 30 days. Every window is below its threshold, no alert is active, and the team reads the healthy budget as permission to keep shipping. The measurement pipeline keeps computing the ratio over each sliding window continuously in the background.
Sudden failure: a bad configuration push sends 30% of requests to errors. Within a couple of minutes the five-minute window's error ratio rockets, and the burn rate over that short window blows past 14.4. But the high-severity page requires the long window too, so it does not fire on the very first noisy sample — the one-hour window needs a few more minutes of sustained failure to cross 14.4 itself. When both the fast and the slow window agree the burn exceeds 14.4, the page fires: 'burning 14x, budget exhausted in ~2 days.' The delay was seconds-to-minutes, not the hour a raw one-hour average would have needed, because the short window did the early detection and the long window only had to confirm.
During the incident: the on-call is paged with the burn rate and time-to-exhaustion already attached. If the outage were milder — a 3% error rate rather than 30% — the fast/high pair would stay quiet and instead the slower 6x or 3x window pair would eventually open a ticket, correctly treating a slow leak as something to fix within days rather than a middle-of-the-night emergency. The severity the responder sees is a direct function of how fast the budget is actually draining.
Recovery and reset: the config is rolled back and errors stop. The five-minute window drops below threshold within minutes, and because the page's condition ANDs the short window, the alert clears almost immediately — the responder is not left acknowledging a page for an incident that ended half an hour ago. The one-hour window stays elevated for a while longer, which is fine: it is no longer sufficient on its own to hold the alert open. The budget ledger records how much was spent during the incident, and if the outage consumed a large slice, the now-depleted budget itself becomes a signal to slow releases until it recovers.