Slack Webhook Alerts: Route Downtime to a Channel

A Slack webhook is the shortest path between a monitor that just went down and the people who can fix it. You create a URL, you POST JSON to it, and the message appears in one channel. The hard part is not the plumbing. It is deciding what belongs in the message and which alerts deserve a channel at all.

What is a Slack webhook?

It is a unique HTTPS URL that accepts a JSON body and posts the result as a message in a workspace. A Slack incoming webhook is the inbound half of the pair, and outgoing webhooks are the opposite direction. Slack's own reference describes it as a way to post messages from apps into Slack, which is exactly as complicated as it gets.

Two constraints shape everything downstream. The channel is bound to the URL when you create it, so the channel field in a payload is ignored for app-based webhooks. And the URL is the credential, since anyone holding it can post as your app.

Ignore the deprecation rumours that follow this topic around. The retirement that caused them was Microsoft's connector shutdown in Teams, not anything on Slack's side.

Creating the URL

Five steps, and none of them need code.

1. Open the Slack API app directory and create a new app, scoped to the workspace you want.
2. Choose Incoming Webhooks in the sidebar and turn the toggle on.
3. Click Add New Webhook to Workspace.
4. Pick the destination channel and authorise it.
5. Copy the Slack webhook URL, which looks like https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX.

Test it before wiring anything to it. A single curl proves the URL, the channel binding and your network path in one shot.

curl -X POST -H 'Content-Type: application/json' \
  --data '{"text":"Test from the monitoring stack"}' \
  https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX

A working call returns the literal string ok. A revoked or mistyped URL returns 404 with no_service, and a malformed body returns 400 with invalid_payload.

What an outage alert should contain

The default text field works and reads badly at 3am. Block Kit lets you put the facts where an eye lands on them. A downtime alert has five of them. What broke, what the check saw, where it was seen from, how long it has been going, and the link to act on.

{
  "blocks": [
    { "type": "header", "text": { "type": "plain_text", "text": "DOWN: checkout API" } },
    { "type": "section", "fields": [
      { "type": "mrkdwn", "text": "*Status*\nHTTP 503" },
      { "type": "mrkdwn", "text": "*Confirmed from*\nLondon, Singapore" },
      { "type": "mrkdwn", "text": "*Down for*\n2m 10s" },
      { "type": "mrkdwn", "text": "*Last good*\n14:02:31 UTC" }
    ]},
    { "type": "actions", "elements": [
      { "type": "button", "text": { "type": "plain_text", "text": "Open status page" },
        "url": "https://example.com/status/api" }
    ]}
  ]
}

The confirmed-from field is the one people add last and value most. An alert that names two regions is a different message from one that names a single probe, because the second might be a routing fault rather than an outage. That is the reasoning behind cross-region quorum.

Wiring it to a monitor

Slack sits among the 16 alert channel types. The usual route is pasting the URL into an alert channel rather than building the POST yourself. Integrations beyond email and web push begin on the Individual plan at $9/mo as of September 2026.

We tested the round trip on a deliberately broken endpoint. A 30 second check confirmed from a second region, and the message landed about 40 seconds after the first failed probe. Most of that was the confirmation window rather than Slack. The delay is a feature, since alerting on one failed check is how channels become unreadable.

Send recoveries to the same channel as the failures. A thread that shows DOWN at 14:04 and UP at 14:09 tells a story, while a channel that only ever reports bad news trains people to mute it. Field names for the monitor side are in the API reference.

Which alerts belong in the channel?

Not every state change deserves a message. Sort them by who has to act, and how quickly.

Event	Channel	SMS or voice
Public endpoint DOWN, confirmed from two regions	yes	yes
Single probe failure, not yet confirmed	no	no
Response time over threshold for ten minutes	yes	no
Certificate expiring in 14 days	yes	no
Heartbeat missed on a nightly job	yes	no
Recovery after an incident	yes	no

The second row is the one teams argue about. A single failed probe from one region is a blip rather than an incident, and pushing blips into a Slack webhook is the fastest way to get the channel muted.

Is a Slack channel enough to page someone?

No, and this is the honest limit of the whole approach. Do not disturb is on by default outside working hours, notifications are per-device, and a muted channel is silent by design. A channel is a notification surface. Paging is a different job.

The split we prefer is boring and works. Route everything to Slack for visibility, and route only user-facing outages to SMS or a voice call, which is what actually wakes someone. Heartbeat failures from batch jobs belong in the channel and almost never on a phone, as covered under heartbeat monitoring.

Common mistakes

Committing the URL. It is a credential with no username attached. Keep it in your secret store, and revoke and recreate it the moment it appears in a repository or a screenshot.

One channel for everything. Certificate expiry warnings, deploy notices and real outages in one stream produce a stream nobody reads. Separate by severity, not by service.

Ignoring the rate limit. Slack allows roughly one message per second per webhook, with short bursts tolerated. A flapping monitor firing into a Slack webhook will start dropping messages exactly when the volume means something.

Posting raw JSON from your monitor into the channel. A payload dump is not an alert. Map the fields you care about into Block Kit once and you will read them for years.

Get the URL, test it with curl, shape a block with the five facts, and keep the channel for visibility rather than for waking people. A Slack webhook is genuinely five minutes of work, and the remaining value is entirely in the editing. If you want the alerts to arrive already shaped, with two-region confirmation behind them, the integration tiers are listed on the pricing page.