Question

Your team runs a payments API with a 99.9% availability SLO measured over a rolling 30-day window. The on-call engineers complain that their current alert—which pages whenever the instantaneous error rate exceeds 0.1%—generates frequent noisy pages for brief, self-recovering blips, yet occasionally fails to warn them about slow, sustained degradations that quietly consume the monthly error budget. You are asked to redesign the alerting to page only when the budget is genuinely at risk. Which approach best meets this goal?

Accepted Answer

Configure multi-window, multi-burn-rate alerts that page on a fast-burn condition (e.g., 14.4x burn over 1 hour combined with a 5-minute short window) and a separate slow-burn condition (e.g., 6x burn over 6 hours).

Answer

Lower the SLO to 99.5% so the error budget is larger and the existing threshold alert fires less often.

Answer

Keep the instantaneous 0.1% error-rate threshold but require the condition to persist for 30 seconds before paging.

Answer

Alert only at the end of the 30-day window when the total error budget has been fully exhausted.