Every channel is configured the same way — Integrations → New integration — and shares the same features: down / up / late events, tag filters, quiet hours, reminders while down, and a delivery journal with retries (3 attempts: 10 s → 1 min → 5 min). Alerts use the account owner's language.
| Channel | You need | Notes |
|---|---|---|
| Telegram | deep-link pairing | DMs and groups; email fallback when the API is down |
| an address | localized HTML mail | |
| Webhook | URL (+secret) | HMAC signature, custom body templates |
| Slack / Discord / Mattermost | incoming webhook URL | markdown messages |
| SMS | phone · Pro+ plan | alert headline only |
| PagerDuty | routing key | up auto-resolves the incident |
Mail arrives as HTML (with a plain-text part for strict clients): a status headline plus details — check, project, time in your timezone, reason. A project can have several email integrations with different filters.
+15551234567).SMS are short — only the alert headline is sent ("🔴 nightly backup is DOWN"). A practical pattern: SMS only for down of critical checks (tag filter), everything else to Telegram/Slack. The channel is unavailable on Free — the form will tell you.
Events API v2 mapping:
trigger, severity critical: an incident opens;resolve with the same dedup_key — the incident closes automatically, no manual resolve;dedup_key = cronalive-<uuid>: a late before a down and repeat reminders land in the same incident instead of spawning new ones;warning (its own dedup key); up does not close it.Do subscribe the PagerDuty integration to up — otherwise you'll be resolving incidents by hand.
The universal tool for every channel is the delivery journal (the Journal button on the integration card): each attempt's status, the attempt count and the provider's error text. pending — quiet hours; suppressed — the service temporarily suppressed down alerts due to an outage of its own workers; failed with a message — a receiver-side problem (wrong key, unreachable address).