Notification Channels

Notification Channels are reusable, project-scoped destinations. One Alert can reference multiple channels. Disable a channel to stop new delivery claims without changing every Alert.

Providers#

• Email accepts a bounded recipient list.
• Generic Webhook sends the stable 2026-08-29 JSON payload and can sign it with HMAC-SHA256.
• Slack and Microsoft Teams use incoming webhook URLs and provider-appropriate message formatting.

Human-facing channels share one bounded Incident presentation but render it natively for each provider:

• Slack uses Block Kit sections, severity/status icons, facts, viewer-local native date tokens, and a View incident button.
• Microsoft Teams uses an Adaptive Card with severity/status icons, FactSets and an Action.OpenUrl incident action.
• Email uses severity/status icons in its subject and responsive HTML incident card, with a complete plain-text alternative.

Group and selected-context maps are presented as readable label/value rows rather than raw JSON. Labels come from the Data Model field description when one is configured and otherwise fall back to a generic rendering of the field name. Analytics result aliases inherit the description of their source dimension or metric field. This keeps terminology governed by each model instead of a domain-specific hardcoded dictionary. Each section is deterministic and bounded to eight fields; long values are truncated, and additional fields remain available on the Incident page. Generic Webhook delivery is unchanged and continues to receive the stable versioned JSON envelope for machine processing.

Alert Rules, Notification Channels, notification deliveries, and Analytics Alert evaluations are plan-metered dimensions. Dashboard plan usage and Workspace limits show current consumption alongside the finite allowance or Unlimited state. Monthly delivery/evaluation counters are persisted after successful quota reservation and restore runtime quota state after Core restarts.

Secrets are encrypted at rest, omitted from API responses, and never written to logs or Assistant model context. Updating a channel can rotate its secret; there is no secret retrieval endpoint.

Generic Webhook security#

Only public HTTPS targets are accepted. URLs with user info are rejected. Redirects are disabled. Core resolves the hostname for each delivery and blocks loopback, private, link-local, multicast, unspecified, and cloud metadata destinations to resist DNS rebinding and SSRF.

Signed requests include:

X-ReportPlane-Timestamp: 1787961600
X-ReportPlane-Delivery-ID: DELIVERY_ID
X-ReportPlane-Signature: v1=HEX_HMAC_SHA256

The signed bytes are:

timestamp + "." + delivery_id + "." + exact_request_body

Consumers should reject timestamps outside their replay window, verify the HMAC in constant time, and deduplicate by delivery ID before processing the body.

The versioned Generic Webhook payload includes Alert identity and severity, Incident status/times/count/reference, deterministic group context, and only explicitly selected fields. It does not include the full raw event by default.

Delivery, rate limits, and retries#

Lifecycle is pending → delivering → delivered, failed, or dead_letter. Network failures, HTTP 408, 429, and 5xx responses retry with jittered exponential backoff capped at 15 minutes. A valid provider Retry-After value is honored. Other 4xx responses are permanent. After at most 5 retryable attempts, the delivery moves to dead_letter; every attempt is retained for audit.

Core coalesces pending work for the same Incident and channel. Database-coordinated limits allow up to 10 delivery claims per channel per minute and 60 per project per minute across Core instances. Excess work is deferred in the queue, not discarded. An authorized operator can manually retry a failed or dead_letter delivery; retry resets it to pending and starts a fresh bounded attempt cycle.

Use Send Test after creating or rotating a channel. A test is an external side effect and is queued through the same asynchronous dispatcher.