Multi-window burn-rate alerts for SLOs

An SLO alert does not fire on one bad minute. It fires when the burn rate — how fast the error budget is being spent — is high enough that the budget will run out, and it checks that the problem is still happening. This is the multi-window, multi-burn-rate method from the Google SRE Workbook.

Burn rate#

burn = error ratio in a window ÷ (1 − objective). A burn of ×1 spends the budget exactly by the end of the SLO window; ×14.4 spends a 30-day budget in about two days.

Default presets#

Each preset needs both windows above the threshold: the long window proves the problem is big enough to matter, the short window proves it is still happening, so an alert stops soon after a fix.

The same factors are used for 7- and 28-day windows; there they are an approximation of the workbook values. A window is only judged when it has measured data; the SLO page shows each window's burn rate, threshold and state under Burn-rate windows.

Alert policy#

Set per SLO in step 4 of the form:

Who receives them#

Every workspace starts with the default alert rule SLO burn, sent to all destinations. In Alerts → Rules you can add SLO rules for one project, some environments or one severity — for example pages to Telegram and tickets to email. Destinations are your own Telegram, Slack, email or webhooks.

• One message when an SLO starts burning, one when it is back within budget. If a slow burn turns into a fast burn, one page is sent.

• A rule does not repeat an alert within 60 minutes.

• An SLO with Not enough data never alerts.

Messages contain the SLO name, project, environment, objective and window, the severity, the burn rates of the windows that fired, the budget left and the times. They never contain request, span or check-in contents. SLOs over spans say that the indicator is estimated.

Webhooks#

Webhooks receive the events slo.burn and slo.recovered. The body's data.slo carries id, slug, name, source, incident_id, severity (page or ticket), objective, window_days, burn (burn rate per window in minutes, null when not judged), budget_remaining, estimated, opened_at and resolved_at.

Pause and mute#

On the SLO page:

• Mute alerts keeps measuring and judging but sends nothing — use it for planned maintenance.

• Pause stops judging and alerting. An open alert is closed without a recovery message.

Both last 1 hour, 4 hours, 24 hours or 7 days, or until you undo them.

If Belvador is unavailable#

SLOs are judged by Belvador every minute. If the control plane is down, SLO alerts arrive late, not lost: counts wait on your node and are judged when it is back. Uptime incidents keep alerting on their own path.