How to Get Slack Alerts for Downtime

An alert that lands in an inbox with 400 unread emails isn't really an alert, it's a message that technically got sent. Most teams don't live in their email during the workday, they live in Slack, which is exactly why a downtime notification buried in a mail client can sit unread for hours while a Slack message in a channel someone's actively watching gets seen in seconds. The monitoring itself isn't the hard part, getting the alert somewhere a human will actually notice is.

This guide covers connecting Slack to Downdar and routing your monitors to alert there.

What You Will Need

A Downdar account, and permission to create an Incoming Webhook in the Slack workspace you want alerts sent to. Depending on your workspace's settings, this may require a workspace admin to approve the webhook, but it doesn't require installing or authorizing a full Slack app.

Connecting Slack to Downdar

Downdar doesn't use a Slack app install or an OAuth prompt for this, it's simpler than that: you create a Slack Incoming Webhook yourself, and paste the resulting URL into Downdar.

Slack Incoming Webhooks are set up from Slack's own API site (api.slack.com/apps), where you create an app scoped to your workspace, enable Incoming Webhooks for it, and choose which channel it should post to. Slack gives you a unique webhook URL for that channel:

https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Copy that URL.

Back in Downdar, go to your alert channels settings, add a new Slack channel, and paste the webhook URL in. That's the entire connection, there's nothing to authorize on Downdar's side beyond that. Downdar creates an alert channel tied to that webhook, which you can reference by name or key when setting up monitors.

If you manage several Slack channels for different purposes, an #incidents channel for anything urgent and a quieter #eng-notifications channel for lower-priority alerts, each one needs its own Incoming Webhook created in Slack, then added to Downdar the same way. Each connected channel gets its own key, so you can route different monitors to different places.

Routing a Monitor's Alerts to Slack

Once a Slack channel is connected, attach it to a monitor using alert_channel_keys, either when creating the monitor or by updating an existing one:

curl -X POST https://downdar.com/api/v1/monitors/create \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "http", "name": "Main website", "host": "https://www.example.com", "alert_channel_keys": ["slack-incidents"] }'

If this monitor already exists, you don't need to recreate it from scratch, updating it with the same key attaches Slack going forward without touching anything else about how the monitor's configured. You can also list alert_channel_keys as an array with more than one entry, so a single monitor can post to Slack and also send an email, for example, rather than picking just one.

Routing Different Monitors to Different Channels

Not every monitor deserves the same channel. A payment API going down is a different kind of urgent than a low-traffic internal tool having a slow response time, and dumping both into the same Slack channel trains people to skim past alerts instead of reacting to them. It's worth deciding upfront which monitors are genuinely "drop what you're doing" and routing only those to a channel with notifications turned all the way up, while sending everything else somewhere lower-stakes that people check periodically rather than react to instantly.

# Critical: customer-facing payment flow "alert_channel_keys": ["slack-incidents"]   # Lower priority: internal admin tool "alert_channel_keys": ["slack-eng-notifications"]

This is worth revisiting occasionally too, it's common for a monitor to start in the "urgent" channel during early setup and never get reassessed once it's actually stabilized and stopped being a real source of incidents.

What Happens When a Monitor Changes State

Once a monitor is connected to Slack, a message posts to that channel the moment its status changes, both when something goes down and when it recovers. That second part matters as much as the first: a team that only gets told about outages and never told when they're resolved tends to assume the worst is still happening long after it isn't, or starts manually checking to confirm, which defeats some of the point of having alerts in the first place.

Get Started

Connect Slack once, then decide which of your existing monitors actually need it before routing everything there at once. A channel that immediately gets noisy is a channel people start muting.