# Notification policies: quiet hours, digests, fallback and escalation

> Hold low-priority messages at night, bundle them into a digest, hand a failed message to a fallback destination and escalate incidents nobody takes — in your time zone.

A **notification policy** decides **when** a message goes out and **what to try next** when it cannot be delivered or nobody reacts. [Alert rules](https://belvador.dev/en/docs/alerts) still decide **who** receives a message; a policy only changes the timing and the backup plan.

Open **Alerts → Notification policies**. Owners and admins manage policies; every change is written to the audit log.

## Which policy applies

Every workspace has a **Default** policy that sends everything right away, with no fallback and no escalation. In **Alerts → Rules → Edit → Notification policy** you can give a rule its own policy; a rule without one uses the workspace default. You can make another policy the default; the default itself cannot be deleted. Deleting another policy moves its rules back to the default, and messages already held still go out at the time planned for them.

A workspace has up to 20 policies.

## Quiet hours

Pick the weekdays, a **From** and an **Until** time and the severities to hold (medium, low or both). A period that runs past midnight — 22:00 to 07:00 — belongs to the evening it starts on. Times follow the policy's **time zone** (IANA, for example `Asia/Ho_Chi_Minh` or `Europe/Berlin`), daylight saving included.

- **Critical and high always go out at once**, even inside quiet hours.
- Held messages go out when quiet hours end. When several are waiting for the same destination, they arrive as **one digest**.
- Messages to **PagerDuty** and **incident.io** are never held — your on-call tool has its own schedules. Test messages, email confirmations, "node unreachable" and connection problems are never held either.

## Digest

**Every hour** or **Daily at** a time, the chosen severities (low by default) are collected into one message per destination: up to 50 lines, then "+N more". A digest is never sent inside quiet hours; it moves to the first slot after them.

## Fallback chain

Add up to 5 destinations in order. When a message still fails after its retries (or its destination is already marked failing), Belvador sends the same message to the next working destination in the chain, once. The switch shows on the incident's timeline. A destination that already got that message is skipped.

## Escalation

For incidents: when nobody takes an incident within the chosen time (5–240 minutes), Belvador sends one "escalated" message to the first destination in the escalation list — a healthy one first, a failing one only if none is healthy. It happens at most once per incident; **taking** the incident stops it. See [Incidents](https://belvador.dev/en/docs/incidents).

## Preview

The **Preview** in the form shows, for a severity and a moment you pick, whether a message would go out now, wait for the end of quiet hours or join the next digest — computed with the same rules Belvador uses when sending.

## API

`GET /v1/notification-policies`, `POST /v1/notification-policies` (create or update) and `DELETE /v1/notification-policies/{policy_id}`, with scopes `alerts:read` and `alerts:write` (admin). The same body works from the [MCP server](https://belvador.dev/en/docs/mcp) configuration tools.