Your API goes down at 2 AM. The first person to notice is a customer who tweets about it. By the time you wake up, there are 30 support tickets and a Hacker News thread about your outage.
This is what happens when you don't have alerts where your team actually looks. And for most engineering teams, that place is Slack.
In this tutorial, you'll learn how to set up Slack alerts for API monitoring with incoming webhooks, whether the alerts come from a monitoring tool or your own check scripts, so you get notified about downtime, latency spikes, error rates, and SSL expiry in the channel where you already work.
Why Slack Is the Best Channel for API Alerts
Engineers don't check email at 2 AM. They don't keep a monitoring dashboard open 24/7. But they do have Slack on their phone with notifications enabled for specific channels.
Slack is where your team already communicates about incidents. When an API alert lands in #ops-alerts, the on-call engineer sees it immediately, and the rest of the team has full context without asking "what happened?"
Compared to other alert channels:
- Emailgets buried, delayed by spam filters, often ignored outside work hours
- SMSlimited formatting, no context, annoying for non-critical alerts
- PagerDuty/Opsgeniegreat for escalation, but overkill for most teams under 20 engineers
- Slackinstant delivery, rich formatting, threaded discussion, mobile push notifications, and it's already open
That's why your alerts should use Block Kit (Slack's rich message format) so you get structured, actionable notifications instead of plain-text noise.
What a Good Slack Alert Contains
Most monitoring tools post to Slack through an incoming webhook, and your own scripts can do the same. Whatever sends it, format the message with Slack's Block Kit so the notification includes:
- Endpoint name and URLe.g.,
Payment API, POST /api/v1/checkout - Current statusDown, Degraded, or Recovered
- Monitoring regionwhich region detected the issue (e.g., US East or Europe)
- Response timethe actual response time vs. your configured threshold
- HTTP status codethe status code returned (e.g., 503 Service Unavailable)
- Timestampwhen the incident was detected
- Direct linka button that takes you straight to the incident, dashboard or logs
This is not a generic "something is wrong" email. It's a structured alert with everything you need to start investigating immediately.
Step 1: Create a Slack Incoming Webhook
First, you need a webhook URL from Slack. This is the endpoint your monitoring tool or script will POST alert messages to.
- Go to api.slack.com/apps and click Create New App
- Select From scratch, name it something like "API Alerts", and choose your workspace
- In the left sidebar, click Incoming Webhooks and toggle it On
- Click Add New Webhook to Workspace
- Select the channel where you want alerts (e.g.,
#ops-alertsor#api-monitoring) - Click AllowSlack will generate a webhook URL
Copy the webhook URL. It will look like this:
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXXKeep this URL private. Anyone with it can post messages to your Slack channel.
Step 2: Send Alerts to the Webhook
If you use a monitoring tool, look for its Slack or webhook integration: paste the URL, send a test notification to confirm it lands in the right channel, and save.
If you run your own checks, posting an alert is a single HTTP request. Include a plain text field as the fallback for notifications, and the blocks for the formatted message:
curl -X POST -H 'Content-Type: application/json' \
--data '{
"text": "API Down: POST /v1/checkout returned 503",
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*API Down*: Payment API\n*Endpoint:* POST /v1/checkout\n*Status:* 503 Service Unavailable"
}
}
]
}' \
"$SLACK_WEBHOOK_URL"Store the webhook URL as a secret (an environment variable, not a value committed to your repo).
Step 3: Configure Alert Rules
Having Slack connected is only half the setup. You also need to define when to alert. Whether you configure it in a tool or in code, start with these rules:
| Alert Rule | Recommended Threshold | Why |
|---|---|---|
| API Down | 2 consecutive failed checks | Avoids false positives from transient network issues |
| High Latency | P95 response time > 2000ms | Catches degradation before it becomes a full outage |
| Error Rate | > 5% of checks return 5xx | Detects partial failures that don't show as full downtime |
| SSL Expiry | Certificate expires in < 14 days | Gives you 2 weeks to renew before HTTPS breaks |
Route each rule to your Slack webhook. You can also add email as a backup, Slack might be down too (it happens).
What the Slack Notifications Look Like
When an alert fires, you'll see a Block Kit formatted message in your Slack channel that looks like this:
API Down, Payment API
Endpoint: POST /v1/checkout
Status: 503 Service Unavailable
Region: Virginia (US)
Response Time: 12,450ms (timeout)
Detected: 2026-03-25 02:14 UTC
[View Incident →]Make the state obvious at a glance (red for down, yellow for degraded, green for recovery), and point the "View Incident" button at wherever the team investigates: the incident timeline in your monitoring tool, a dashboard with the latency breakdown (DNS, TLS, TTFB), or the logs.
When the endpoint recovers, you get a follow-up notification:
Recovered, Payment API
Endpoint: POST /v1/checkout
Status: 200 OK
Region: Virginia (US)
Response Time: 187ms
Downtime: 8 minutes
Recovered: 2026-03-25 02:22 UTC
[View Incident →]Anti-Spam: One Notification per Incident
Nobody wants their Slack channel flooded with repeated alerts every 60 seconds. Use a one notification per incident model (most tools support it; in your own scripts, store the current state and only post when it changes):
- 1 alert when the incident starts (after the configured threshold is crossed)
- 1 recovery notification when the endpoint is healthy again
- No repeated alerts during an ongoing incident
This means if your API is down for 30 minutes, you get exactly 2 Slack messages, not 30. Your #ops-alerts channel stays clean and every message in it is worth reading.
If you need more granular updates during an incident, keep the full timeline with every individual check result in your monitoring tool or dashboard, not in the channel.
Pro Tip: Create a Dedicated Alert Channel
Don't send API alerts to #general or #engineering. Create a dedicated channel like #api-alerts and configure it so:
- Only monitoring tools post to it (your uptime checker, your CI/CD, etc.)
- On-call engineers have mobile notifications enabled for this channel
- Everyone else can check it when they need context on an incident
This keeps your main channels clean while ensuring alerts never get lost in conversation noise.