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.

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 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.