Alerting channels and routing

Notification destinations, incident routing, delivery schedules, and retries.

Alert channels deliver incident notifications to configured destinations. Each channel defines a destination, routing rules, and delivery intervals. Manage channels in the Alerts workspace:

• Channels: create, edit, test, enable, and delete channels.
• Deliveries: the newest 200 delivery attempts across all channels.
• Coverage: which monitors are reached by at least one enabled channel.

Channel typesLink kopiëren

A channel's type is fixed once created. The type selector is locked while editing; create a new channel instead of changing the type.

WebhooksLink kopiëren

The body is a template you control. It must render as valid JSON, and each placeholder is substituted as a JSON value—a title containing quotes cannot break the document. Available placeholders include {{event}}, {{delivery.id}}, {{incident.id}}, {{incident.title}}, {{incident.status}}, {{incident.severity}}, {{incident.startedAt}}, {{incident.resolvedAt}}, {{incident.url}}, and {{incident.monitors}}.

Every request carries:

X-Status-Event: incident.triggered
X-Status-Delivery: <delivery id>
X-Status-Timestamp: <unix seconds>
X-Status-Signature: sha256=<hex>

The signature is HMAC-SHA256(secret, "<timestamp>.<body>") over the exact bytes sent. Verify it before trusting a request, and reject timestamps far from your own clock. The secret is displayed once, when the channel is created, and is never shown again; editing a channel never rotates it.

Custom headers are supported. Redirects are not followed—a redirected webhook is treated as a delivery failure.

Chat providersLink kopiëren

Treat the complete Slack, Teams, or Discord webhook URL as a credential. The console displays the host and masks the remaining URL. Provider hostname validation rejects URLs targeting unrelated origins.

Teams needs the body shape its endpoint expects. Power Automate Workflows accept an Adaptive Card (the default); the retired Office 365 connectors accept a MessageCard. Pick the one matching the URL you pasted.

PagerDutyLink kopiëren

Triggers and recoveries use the incident's own ID as the PagerDuty dedup key, so a repeat reminder updates the existing PagerDuty incident instead of opening a second one, and a recovery resolves exactly the alert it opened. Status severities map to PagerDuty's as critical → critical, major → error, and minor → warning. The optional Source label is shown as the alert source in PagerDuty.

EmailLink kopiëren

Email channels use the relay configured in Settings → Instance → Mail relay. Without a relay, the form shows a warning and delivery returns an error. Send test sends a message to the current user’s address using saved settings.

Browser pushLink kopiëren

A push channel has no destination of its own. It reaches whichever browsers people in the organization have registered under Settings → Notifications → Devices, and each browser registers separately—signing in on a second machine does not carry a subscription across.

Notifications are tagged by incident, so an incident's progress replaces its earlier notification rather than stacking a new one. When a browser discards its subscription, that device is removed without affecting the others. Browser push requires HTTPS.

RoutingLink kopiëren

Open the Routing section of the channel editor. Every condition must match:

• Monitors. Leave empty to alert on every monitor in the organization. Otherwise the incident must affect at least one selected monitor.
• Severities. Only incidents at a selected severity are sent. Severity comes from the severity rules for automatic incidents, or from the declaration for manual ones.
• Events. Choose which events reach the channel:
  • Triggered — a new incident opened, or a resolved one reopened.
  • Recovered — the incident resolved. Never held back by quiet hours.
  • Repeat reminder — re-sent while an incident stays open.
  • Critical setup health, Critical infrastructure, Critical delivery — grouped events for conditions that threaten detection, reliability, or delivery.

PacingLink kopiëren

• Cooldown suppresses further triggers on that channel for the configured period. Recoveries are never suppressed: withholding an all-clear leaves an operator believing an incident is still open.
• Repeat every re-sends an open incident on an interval. It requires the repeat event, and the reminder is skipped when a trigger or reminder already went out inside the window.
• Quiet hours hold triggers and reminders until the window ends, in the timezone you choose, on the days you choose. Recoveries always go out.

Grouping happens upstream: automatic incidents already group by taxonomy, so a folder-wide outage produces one incident and therefore one alert per channel, not one per monitor.

Delivery and retriesLink kopiëren

A failed delivery is retried with exponential backoff—30 seconds, one minute, two minutes, and so on, up to an hour—for eight attempts, then marked failed. Every attempt is recorded: the Deliveries view shows status, attempt count, the response status or error, and when the next attempt is due.

Send a test notification on a channel row sends immediately and reports the result, so a wrong URL or credential surfaces at the moment you press it rather than during the next incident. Test sends are recorded in the delivery history too.

Manage channelsLink kopiëren

• Enabled: a disabled channel receives nothing. Use it to suspend a channel without deleting its configuration.
• Delete channel…: removes the channel and its delivery history. Incidents keep alerting through any other channel.

Viewers can read the Alerts page; creating, editing, testing, enabling, and deleting channels requires Member or above. Channel changes are written to the audit log.

Related documentationLink kopiëren

• Status help center
• Incidents
• Notification center