Burn-rate alert

An alert that pages when failures are using up the service's allowed error budget too quickly.

“burn rate alret”“tell me when the error budget is disappearing”“alert before we use up the monthly reliability budget”“errors are happening too fast”“slo alert that ignores tiny blips”“how fast are we burning reliability”“page on sustained bad requests”“only wake me if this will blow the whole month”

See it

Live demo coming soon

What it is

A burn-rate alert fires when a service is consuming its error budget faster than the SLO allows. A burn rate of 1 spends the budget evenly across the whole window; 10 means the current failure rate would spend it ten times faster. This ties paging to customer-visible reliability instead of an arbitrary error count.

Reach for it when you have an SLO and error budget but threshold alerts are either noisy or too slow. The multiwindow method from Google's SRE Workbook pairs a long window with a short one, so an alert needs both sustained impact and evidence that the problem is still active.

Gotcha: a short window alone flaps on tiny spikes, while a long window alone can keep firing after recovery. Low-traffic ratios can also jump wildly on one request. Require both windows, keep page and ticket thresholds separate, and test the rule against zero-traffic periods.

Ask AI for it

Create Prometheus multiwindow burn-rate alerts for a 99.9 percent SLO over 30 days. Define burn rate as the ratio of 5xx request rate to total request rate, divided by 0.001. Page when both the one-hour and five-minute rates exceed 14.4, and page at lower priority when both the six-hour and 30-minute rates exceed 6. Implement the calculations as Prometheus recording rules, route pages through Alertmanager, suppress zero-traffic division, and add promtool tests for healthy, fast-burn, slow-burn, recovered, and no-traffic cases.

You might have meant

error budgetsloalert thresholdgolden signalsmetric