Email alerts get buried, SMS costs money, and a status dashboard only helps if someone is looking at it. If your team already lives in Discord, the fastest place to learn that your site is down is the channel you're already staring at. A Discord webhook makes that a two-minute setup with no server and no account beyond the ones you have.
Step 1 — Create the Discord webhook
In Discord, open Server Settings → Integrations → Webhooks → New Webhook. Pick the channel the alert should land in (a dedicated #alerts channel keeps noise out of chat), give it a name like "Uptime", and click Copy Webhook URL. It looks like https://discord.com/api/webhooks/123.../abc.... Treat that URL like a password — anyone who has it can post to your channel.
Step 2 — Understand what Discord expects
A Discord webhook accepts a JSON POST with a content field (and optionally rich embeds). The simplest possible message:
curl -H "Content-Type: application/json" \
-d '{"content":"🔴 example.com is DOWN (HTTP 503)"}' \
"https://discord.com/api/webhooks/123.../abc..."
Run that and the message appears in your channel instantly. That is the entire alerting mechanism — the hard part isn't posting to Discord, it's knowing when to post: checking the site continuously, debouncing flapping, and remembering to send a recovery message when it comes back.
Step 3 — Let something check the site for you
You could write a cron job that curls your site every minute, compares the status, tracks state so you only alert on changes (not every minute it's down), and posts to Discord. In practice that script grows: retries to avoid false alarms on a single blip, a recovery notice, latency thresholds, keyword checks for pages that return 200 while broken. This is exactly what an uptime monitor does, and pointing one at your Discord webhook skips all of it.
With NotDown you paste your site URL and your Discord webhook URL, and it checks every minute from the edge. On a state change it posts a formatted alert — down with the status code or error, then a recovery message with how long the outage lasted — so the channel reads like a clean timeline instead of a firehose.
# the whole setup, via API — or do it in the UI in 10 seconds
curl https://notdown.notdown-app.workers.dev/api/quick \
-H "content-type: application/json" \
-d '{"target":"https://example.com",
"webhook":"https://discord.com/api/webhooks/123.../abc..."}'
Avoiding alert fatigue
- Alert on transitions, not states. Post once when it goes down and once when it recovers — never once per check. A monitor tracks this for you.
- Confirm before crying wolf. A single failed request is often a network blip. Re-check before alerting so one dropped packet doesn't wake the channel.
- Send recovery, always. A "down" with no matching "back up" leaves everyone wondering. The recovery message with outage duration is the one people actually thank you for.
- Use a dedicated channel. Route alerts to
#alerts, not the main chat, so they stay scannable and don't drown in conversation.
Slack, or anything else
The same pattern works for Slack (Incoming Webhooks use a text field instead of content) and for any endpoint that accepts a JSON POST — a Microsoft Teams connector, a PagerDuty events URL, or your own HTTP handler. Pick the webhook your team already watches; the monitor doesn't care where the alert lands.
NotDown sends down + recovery alerts to Discord, Slack, or any webhook on the free tier, with 1-minute checks and no account required to try it. Check a URL now → or set up continuous monitoring →