Notification Channels: Where Alerts Go
Email, Slack and Discord are live today. SMS, phone and web push are designed and not yet shipped, and this page says which is which.
A notification channel is a destination for alerts. You add channels to your account, bundle them into notify groups, and attach groups to the things you are watching.
Below is what works today and what does not, stated plainly, because discovering a channel is a stub after you have built your alerting around it is a bad afternoon.
Current status by channel
| Channel | Status | Available on |
|---|---|---|
| Live | All tiers including Free | |
| Slack | Live | Starter and above |
| Discord | Live | Starter and above |
| SMS | Not yet implemented | Planned for Team |
| Phone call | Not yet implemented | Planned for Team |
| Web push | Not yet implemented | Designed, not built |
SMS and phone exist in the data model but there is no telephony provider wired up behind them. Web push is designed down to the VAPID keys and service worker and has not been built.
If SMS or voice escalation is a hard requirement for your on-call rotation today, we are not the right choice yet and you should look at a tool that has shipped it. We would rather say that here than have you find out during an incident.
Delivery is queued, never inline
When an alert fires, the notify group is resolved to its qualifying channels and one job is queued per channel. Nothing sends during the request that triggered it.
This matters more than it sounds. A Slack webhook that has become slow should not delay detection of the next problem, and a channel that fails should not prevent the other channels in the same group from delivering.
Each channel type has its own job class with retries and exponential backoff, so a transient failure at one provider recovers without anyone intervening.
Per-delivery tracking
Deliveries are recorded separately from alerts, one row per channel per event. One alert fanning out to 4 channels produces 4 delivery records, each with its own success or failure state.
That separation is what lets a chronically broken channel be identified. A Slack webhook whose app was uninstalled fails every time, and the channel gets flagged rather than quietly swallowing every notification routed through it.
It is worth checking that flag occasionally. A notify group pointing exclusively at a dead channel looks like coverage and provides none.
Severity floors
A channel's minimum level is set per group membership rather than on the channel itself, which means the same email address can receive everything in one group and only critical alerts in another.
Typical setup is email and Slack at info so the team sees completions and warnings as well as failures, with anything interrupting a person reserved for critical.
Channel limits by plan
| Free | Starter | Team | Enterprise | |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | |
| Slack and Discord | No | Yes | Yes | Yes |
| Channels per group | 1 | Unlimited | Unlimited | Unlimited |
Free is email only. That is enough to catch the failures the free tier is sized for, and Slack is the first thing most people want when they outgrow it.
Testing a channel
Send a test notification when you add a channel, and again after any change to the destination. A Slack workspace migration, a rotated webhook URL or a renamed Discord channel all break delivery silently, and the test is the only way to find out before a real alert does.
See notify groups for routing and escalation, and alerts for what triggers delivery.