How to set up alerts for Docker containers (Slack, Discord, Telegram)

When a production container goes down at 3 AM, you have two options: find out from your monitoring system, or find out when a user tweets about it. Docker container alerts are the difference between those two options. This guide shows you exactly how to configure alerts for Slack, Discord, and Telegram — including real webhook setups, threshold strategies, and how to avoid the alert fatigue that makes teams disable their monitoring entirely.

Why email-only alerts fail at 3 AM

Email is fine for low-severity events. It's terrible for incidents. The problems:

1. No mobile push notification by default — unless you've configured your email client to alert you for specific senders, every alert email looks the same as a newsletter
2. Batching and threading — if a container crashes and restarts 10 times, you might get those 10 alerts collapsed into one thread, or the notification priority might be dropped
3. Context switch cost — opening email takes you out of your current task; Slack/Discord notifications are glanceable
4. No channel-based routing — you can't easily say "P0 alerts go to #oncall, P2 alerts go to #infrastructure-warn"

The goal is: container down → visible notification → someone on your team sees it in under 5 minutes. Email rarely achieves this reliably.

Setting up a Slack webhook for Docker alerts

Slack's incoming webhooks are the easiest way to get alerts into a channel.

Step 1: Create a Slack app

1. Go to api.slack.com/apps and click Create New App
2. Choose From scratch, name it "Kernus Alerts" (or whatever you prefer)
3. Select your workspace
4. Under Add features and functionality, click Incoming Webhooks
5. Toggle on Activate Incoming Webhooks
6. Click Add New Webhook to Workspace
7. Choose the channel for alerts (create #production-alerts if you don't have one)
8. Copy the webhook URL — it looks like: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Step 2: Test the webhook

curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"Test alert from Docker monitoring"}' \
  https://hooks.slack.com/services/YOUR/WEBHOOK/URL

If you see ok as the response and a message appears in your channel, the webhook works.

Step 3: Configure in Kernus

In the Kernus dashboard, go to Settings → Notification Channels → Add Channel → Slack. Paste your webhook URL. That's it — every alert rule can now target this Slack channel.

Step 4: Create the alert rule

In Dashboard → Alerts → Create Rule:

Name: Production container down
Condition: Container is down
Duration: Immediately (0 minutes)
Channels: [Your Slack webhook]

For memory alerts, add a duration so you don't alert on brief spikes:

Name: High memory usage
Condition: Memory above 85%
Duration: 10 minutes
Channels: [Your Slack webhook]

What a Kernus Slack alert looks like when it fires:

• Container name and host
• Condition that triggered (e.g., "OOM Kill - exit code 137")
• Exit reason if available
• Last 5-10 log lines from the container
• Direct link to the container in your dashboard

The last two points matter: you don't have to SSH into the server just to understand why something broke.

Setting up a Discord webhook for Docker alerts

Discord webhooks work similarly to Slack but are set up in your server's channel settings.

Step 1: Create the webhook in Discord

1. Open your Discord server settings → Integrations → Webhooks
2. Click New Webhook
3. Give it a name ("Kernus Alerts") and optionally set an avatar
4. Choose the channel (create #production-alerts if needed)
5. Click Copy Webhook URL — it looks like: https://discord.com/api/webhooks/1234567890/XXXXXXXXXXX

Step 2: Test the webhook

curl -X POST -H "Content-Type: application/json" \
  -d '{"content": "Test alert: api-gateway container restarted"}' \
  https://discord.com/api/webhooks/YOUR_WEBHOOK_URL

Step 3: Configure in Kernus

Settings → Notification Channels → Add Channel → Discord. Paste the webhook URL.

Discord alerts from Kernus come formatted as rich embeds — color-coded by severity (red for crashes, amber for warnings), with fields for container name, node, condition, and log context.

Why Discord for alerts?

Discord has a few advantages over Slack for small teams:

• Mobile notifications are more reliable — Discord's mobile app is aggressive with push notifications by default
• Free forever — Slack free tier limits message history to 90 days and has some feature restrictions
• Most indie dev teams already use it — if your team lives in Discord anyway, adding a #alerts channel is zero friction

Setting up a Telegram bot for Docker alerts

Telegram is popular for server alerts because it's fast, has excellent mobile notifications, and the bot API is simple.

Step 1: Create a Telegram bot

1. Open Telegram and search for @BotFather
2. Send /newbot
3. Choose a name (e.g., "Kernus Alerts")
4. Choose a username (must end in bot, e.g., KernusAlertsBot)
5. BotFather gives you a token: 1234567890:ABC-DEF1234ghIkl-zyx57W2v1u123ew11

Step 2: Get your Chat ID

1. Start a conversation with your new bot (search for it by username and press Start)
2. Send any message to the bot
3. Open this URL in your browser (replace TOKEN with your bot token):

   https://api.telegram.org/botTOKEN/getUpdates
   

4. Find "chat":{"id":XXXXXXXXX} in the response — that's your chat ID

For a group chat: add the bot to the group, send a message mentioning it, and use the same getUpdates URL to find the group's chat ID (it'll be negative, like -1001234567890).

Step 3: Test the bot

curl "https://api.telegram.org/bot{TOKEN}/sendMessage" \
  -d "chat_id={CHAT_ID}" \
  -d "text=Test alert: api-gateway container is down"

Step 4: Configure in Kernus

Settings → Notification Channels → Add Channel → Telegram. Enter your bot token and chat ID in the format CHAT_ID:BOT_TOKEN.

SMS alerts: when everything else fails

SMS is the nuclear option — it wakes people up. Use it for P0 alerts only.

Kernus supports SMS via Twilio. In Settings → Notification Channels → Add Channel → SMS, enter a phone number in E.164 format (e.g., +15551234567).

When to use SMS:

• Container down in production that hasn't recovered in 5 minutes
• OOM kill loop (container restarting every 30 seconds)
• Multiple containers down simultaneously (potential host failure)

When not to use SMS:

• Warning-level alerts (high CPU, approaching memory limit)
• First restart (might self-heal)
• Non-critical services

Alert threshold strategies that actually work

Getting thresholds right is harder than getting channels set up. Bad thresholds lead to alert fatigue, which leads to alerts being ignored, which defeats the purpose.

The "sustained vs instantaneous" rule

Never alert on instantaneous metric values. Always require the condition to be true for a minimum duration.

The exception: container down. Flash OOM kills and immediate crashes you want to know about quickly. But give it 30-60 seconds to self-recover before alerting.

Tier your alerts by channel

P0 (Container down, OOM kill loop, host unreachable):
  → SMS + Slack #oncall

P1 (Sustained high memory, restart storm, disk full):
  → Slack #oncall + Discord #alerts

P2 (Memory approaching limit, slow response pattern):
  → Slack #infrastructure-warn

P3 (First restart, CPU spike):
  → Email digest (weekly)

Container-aware thresholds

Don't use the same thresholds for every container. Configure separate alert rules per container or container group:

• Databases — alert at 75% memory (they're sticky, unexpected growth is bad)
• Stateless APIs — alert at 85-90% memory (they should be near-constant)
• Batch workers — alert on duration, not peak memory (spikes are expected)
• Cache services (Redis) — alert when approaching maxmemory limit, not raw usage

Testing your alerts before they matter

This is the step most teams skip. Don't be that team.

# Stop a container manually to trigger a "container down" alert
docker stop my-api-container

# Wait for the alert to fire (should be under 2 minutes)
# Verify it arrives in Slack/Discord/Telegram

# Start it back up
docker start my-api-container

Kernus also includes a Test Alert button on each notification channel. Use it. The test sends an example alert payload to that channel so you can verify formatting looks correct, mentions work, and the notification actually wakes up your mobile device.

How Kernus handles multi-channel alerting

One alert rule in Kernus can target multiple channels simultaneously. Create a single "Container Down" rule and route it to Slack + Discord + SMS all at once. You don't need to create duplicate rules per channel.

The alert payload is adapted for each channel:

• Slack and Discord get rich embeds with color coding, fields, and structured data
• Telegram gets formatted HTML with bolded labels
• SMS gets a concise plain text message with the essential info
• Email gets a full HTML template with charts-linked context
• Webhook gets the full JSON payload for your own processing

---

For the broader monitoring setup: Docker container monitoring complete guide. For getting notified when a container goes down specifically: How to get alerted when a Docker container goes down.

Set up Docker container alerts in 2 minutes →