Updated 2026-06-24
Webhook channels are built so you can point Status at your own tooling — Slack, PagerDuty, an internal ingestion endpoint — without writing a translation shim.
Payload presets
When you create a webhook, you pick a starting payload preset: generic, Slack, Discord, PagerDuty, Opsgenie, Teams, or fully custom. Presets are just a starting template — pick one and edit it freely afterward.
The template syntax
Payloads use a small, deliberately limited template syntax — no code execution, no loops or conditionals:
{{path.to.var}}inserts a value as an escaped string (you supply the surrounding quotes) — for example"name": "{{check.name}}".{{{path.to.var}}}inserts a raw JSON value (numbers, booleans, arrays) — for example"duration_seconds": {{{incident.durationSeconds}}}.
Available variables cover the check (check.name, check.type,
check.target, check.tags), the incident (incident.cause,
incident.startedAt, incident.confirmations, incident.regions), the
triggering result (result.statusCode, result.responseMs, result.error),
and deep links back into your dashboard (urls.incident, urls.check,
urls.statusPage). The full catalog is shown as clickable chips in the
webhook editor.
Validation
When you save a webhook (or use the preview endpoint), your template is rendered against a sample event and checked: if the channel's content type is JSON, the rendered output must parse as valid JSON, or you'll see an error with the line and column to fix. The same re-validation happens again at actual delivery time as a safety net — if a real event were ever to somehow produce invalid JSON, nothing is sent and the attempt is logged as failed rather than delivering garbage to your systems.
Signing
Every webhook delivery can be signed with X-Status-Signature, an
HMAC-SHA256 over the request timestamp and body using your account's
webhook secret. Your receiver can verify the signature to confirm a request
really came from Status. The secret is rotatable from account settings.
Custom headers
You can add custom headers (for example an Authorization header for your
receiver) up to your plan's limit. Header values are encrypted at rest.
Certain headers (Host, Content-Length, Transfer-Encoding, Connection)
can't be overridden, and header injection attempts are rejected outright.
Delivery and destination safety
Every webhook destination is checked at save time — and again at every delivery, since DNS can change — to reject private, loopback, and metadata network ranges, so a webhook can't be pointed at internal infrastructure. Failed deliveries retry with backoff before the channel is disabled (see Email and webhook alert channels).
Per-check alert thresholds
Alerting behavior is tuned per check, not with one account-wide setting:
- Confirmations — how many regions must agree before the check is down (see How multi-region confirmation works).
- Alert delay — an optional dwell period after confirmation before the first notification goes out, in case the check recovers on its own first.
- Re-alert interval — an optional repeating reminder while an incident stays open (higher plans).
- Escalation — an optional second wave of channels notified if the incident is still open after a longer delay (Enterprise).