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 · launching soon |
| 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.
The channel is launching soon: the integration UI is already in the dashboard, delivery goes live once the SMS provider is connected.
+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.
Start with the Send-a-test-alert button on the integration card: the message goes through the real channel (at most once per 30 seconds) and the result shows up in the journal right away. The universal tool for every channel is the delivery journal (the Journal button): each attempt's status, the attempt count and the provider's error text. pending — quiet hours; suppressed — either the service temporarily suppressed down alerts due to an outage of its own workers, or the check is unstable and flap damping kicked in (the reason is shown in the journal); failed with a message — a receiver-side problem (wrong key, unreachable address).