Webhooks & alerts

Webhooks push events from error.page to wherever your team already works — Slack, Zendesk, PagerDuty, or your own HTTP endpoint — so an incident reaches you without anyone watching a dashboard.

Webhooks are a Business-plan feature.

Events

Event	Fires when
error.created	A new incident is seen for the first time
incident.acknowledged	Someone acknowledges an incident
incident.resolved	An incident is resolved — manually, by auto-resolve, or on a production release (payload includes release when applicable)
incident.regressed	A resolved incident recurred — high severity (severity: high)

Adding an endpoint

From Webhooks in the dashboard, add a destination URL. error.page generates a signing secret for it. Choose which events it should receive.

Delivery & security

• Deliveries are queued and retried with exponential backoff, so a brief outage at your endpoint doesn't lose events.
• Every request is signed with an HMAC-SHA256 signature derived from your endpoint's secret. Verify it to be certain the payload really came from us:

signature = HMAC_SHA256(secret, raw_request_body)

Compare it (in constant time) against the signature header on the request.

• Endpoint URLs must be HTTPS and are checked against SSRF protections — private and reserved IP ranges are rejected, so a webhook can't be pointed at internal infrastructure.
• After repeated failures an endpoint is automatically disabled so a dead URL doesn't retry forever. Re-enable it once fixed.

Slack & Zendesk

Point a webhook at a Slack incoming webhook URL and events arrive as formatted messages. For Zendesk or other tools, use their inbound webhook/trigger URL — the JSON payload contains the incident type, message, count and a link back to the dashboard.

Delivery log

Each endpoint keeps a log of recent deliveries with response status, so you can confirm events are arriving and debug failures.