The right alert, on the right channel.

A payments outage should page someone. A marketing site blip can wait in Slack. Route each monitor to the channels it deserves.

Routing is per monitor, not all-or-nothing.

Alert fatigue starts the day every failure goes to every channel. Here, channels are attached to individual monitors: the payments API pages the on-call engineer through PagerDuty, the marketing site posts to Slack, and the nightly backup job pings an ntfy topic nobody has to watch in real time.

Channels are defined once at the team level, so a Slack webhook you configure today can be attached to the next twenty monitors in two clicks.

Notification routing Enabled
Payments API
on-call rotation
PagerDuty
Marketing site
#alerts
Slack
Customer webhooks
ops team
Opsgenie
Nightly backups
backups topic
ntfy

One slow webhook never blocks the page.

Every notification is dispatched as its own queued job: three attempts, 30-second backoff, per channel. If your webhook receiver is timing out at 3 a.m., PagerDuty still fires on time and Slack still gets the message.

Failed deliveries are logged with the channel and the reason, so "did the alert go out?" has an answer you can look up instead of a shrug.

api.acme.com is down Critical
PagerDuty
triggered, severity critical
sent
Slack
#incidents
sent
Webhook
receiver timed out
retry 2 of 3

What notifications include.

Alerts are not a pricing lever.

Attach as many channels as you like to any monitor. Free covers 5 monitors and 1 status page, Pro is $9 per month for 100 monitors and 10 status pages, and both route to all 10 channel types. Nobody meters who got paged.

"severity": "critical"

Channels are API records too.

Like monitors, notification channels are rows in an API, not settings buried in a UI. Create them from a provisioning script, attach them to monitors, and disable one temporarily without deleting its config.

Each channel stores its own credentials: a webhook URL for Slack, Discord, or Teams, a routing key for PagerDuty, an API key for Opsgenie.

curl -X POST https://uptime-status.org/api/notification-channels \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "On-call Slack",
    "type": "slack",
    "config": "{\"webhookUrl\": \"https://hooks.slack.com/...\"}"
  }'
FAQ

Notifications, answered.

Which channels are supported?

Email, SMS, Slack, Discord, Microsoft Teams, PagerDuty, Opsgenie, Pushover, ntfy, and plain webhooks. Ten in total, and every plan gets all of them.

Can different monitors alert different channels?

Yes, that is the default model. Channels are defined once at the team level, then attached per monitor. Your payments API can page the on-call engineer while the marketing site posts to a Slack channel.

Will a slow webhook delay my page?

No. Every notification is dispatched as its own queued job with three attempts and a 30-second backoff. A webhook receiver timing out has no effect on the PagerDuty or Slack deliveries happening alongside it.

Do I get an alert for every incident update?

No, and that is deliberate. Channels fire when an incident opens and when it resolves. Status changes in between land on the incident timeline and the status page without re-paging everyone.

What does the alert actually say?

The subject names the monitor that went down. The message carries the failure cause the check recorded, such as the HTTP status or connection error, so the alert starts the fix instead of a search.

Start monitoring in under 2 minutes.

No credit card required for the self-hosted, open-source version.