SLO-based alerting and error budgets

WHAT THIS TESTS Whether you can connect SLOs to actionable alerting through the error-budget and burn-rate model, rather than picking arbitrary thresholds.

A GOOD ANSWER COVERS First define an SLI, a measurable indicator like the fraction of successful requests, and an SLO, the target, say 99.9 percent over 28 days. The error budget is the complement: 0.1 percent of requests may fail in that window. Instead of alerting on a fixed error rate, alert on burn rate, the speed at which you are consuming the budget. A burn rate of 1 means you will exactly exhaust the budget by the window's end; higher means faster. The standard approach is multi-window, multi-burn-rate alerting: a high burn rate over a short window, for example consuming a large share of the budget in an hour, pages immediately because impact is severe; a lower burn rate sustained over a longer window raises a ticket because it is a slow leak that still threatens the SLO. Combining a short and long window in each rule reduces false positives from brief spikes while keeping detection fast for real problems. This ties alert urgency directly to user impact and remaining budget.

COMMON WRONG ANSWERS Using one static error-rate threshold, which either pages on harmless blips or misses slow burns. Treating the SLO target itself as the alert threshold. Ignoring multi-window confirmation, leading to flapping. Forgetting that exhausted budget should also gate risky releases.

LIKELY FOLLOW-UPS Why two windows per rule? How do you pick burn-rate thresholds? How does the error budget influence release decisions?

ONE CONCRETE EXAMPLE With a 99.9 percent SLO, you set a fast-burn page when the 1-hour and 5-minute windows both show a 14x burn rate, meaning 2 percent of the monthly budget gone in an hour, and a slow-burn ticket when the 6-hour and 30-minute windows show a 1x burn. The fast rule catches outages quickly; the slow rule catches a steady degradation before it silently eats the whole budget.