# Multi-window burn-rate alerts for SLOs

> The three default burn presets, page and ticket policies, alert rules, message contents, webhook events, pausing and muting.

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.

| Severity | Long window | Short window | Fires when both exceed | Budget spent when it fires (30-day window) |
|---|---|---|---|---|
| **Page** (fast burn) | 1 h | 5 min | ×14.4 | 2 % |
| **Page** (fast burn) | 6 h | 30 min | ×6 | 5 % |
| **Ticket** (slow burn) | 3 d | 6 h | ×1 | 10 % |

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:

| Policy | Sends |
|---|---|
| **Page and ticket** (default) | Fast burn as a page, slow burn as a ticket |
| **Page only** | Fast burn only |
| **Ticket only** | Slow burn only |
| **No alerts** | Nothing; the SLO is still measured and shown |

## 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](https://belvador.dev/en/docs/alerts).

- 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](https://belvador.dev/en/docs/alerts/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.