How to Set Up Slack Downtime Alerts
How to Set Up Slack Downtime Alerts
Email works for incident summaries. It does not work for incidents in progress. By the time an engineer opens an email about a 503, scans it, and figures out what is affected, the incident is already three minutes old.
Slack alerts are faster, more visible, and easier to act on. This guide walks through connecting Nodown to Slack, configuring which channels receive which alerts, and filtering by severity so your team is not paged for every transient blip.
What a Slack downtime alert should contain
Before connecting anything, it is worth being clear on what a useful alert looks like.
A Slack alert that just says "your site is down" is not useful. A useful alert contains:
- The monitor name and URL that failed
- The failure reason (unexpected status code, keyword not found, latency exceeded, SSL expiry)
- The time the failure was first detected
- A direct link to the monitor in your dashboard
That is the difference between an alert that sends your team to investigate and an alert that makes your team ask "what do I even do with this?"
Nodown's Slack alerts include all of this by default. Recovery notifications include the total downtime duration so you have incident length without having to calculate it manually.
Connecting Nodown to Slack
Step 1: Create a Slack Incoming Webhook
Go to your Slack workspace, open Apps, and search for Incoming Webhooks. Add it to your workspace if it is not already there.
Select the channel you want alerts to post to - start with a dedicated #downtime or #monitoring channel, not #general. Click Add Incoming Webhooks Integration. Slack generates a webhook URL that looks like https://hooks.slack.com/services/T.../B.../....
Copy that URL. You will need it in the next step.
Step 2: Add the Slack integration in Nodown
In your Nodown dashboard, go to Alerting and open the Integrations tab. Select Slack from the list of available channels.
Paste the webhook URL you copied from Slack. Give the integration a name - something like "Slack #downtime" - so it is identifiable when you have multiple alert channels configured.
Click Test to send a sample alert to the channel. If the test message appears in Slack, the connection is working.
Step 3: Attach the integration to your monitors
An alert integration does nothing until you attach it to a monitor. In Nodown, go to Monitoring and open any monitor you want to route to Slack. Under Alert Channels, select the Slack integration you just created.
Do this for each monitor you want Slack alerts for. You can attach multiple integrations to a single monitor - for example, Slack for immediate team visibility and email for a paper trail.
Routing alerts to different channels by severity
One channel for all alerts creates noise. A P1 alert - your main API is down - should not compete for attention with a P3 alert about a secondary docs endpoint responding slowly.
Set up two or three Slack integrations pointing to different channels, then assign them to monitors based on severity.
Recommended channel structure:
#incidents-critical - Production API, authentication endpoint, payment flows. Any monitor where downtime has direct user or revenue impact. Alert immediately, every failure.
#incidents-secondary - Marketing site, docs, admin panels, staging environments. Alert after two consecutive failures to reduce noise from transient issues.
#monitoring-digest - Recovery notifications and low-priority alerts. Optional, but useful for teams that want a full audit trail without cluttering the main incident channel.
In Nodown, create a separate Slack integration for each channel with its own webhook URL. Assign monitors to the corresponding integration based on their criticality.
Reducing alert noise
Alert fatigue is a real problem. When a Slack channel pings every few minutes for false positives, engineers start ignoring it - including the real ones.
Set consecutive failure thresholds. In Nodown, each monitor has an option to alert only after two or three consecutive failed checks. A single failed check from one region might be a network blip between that region and your server. Two consecutive failures from multiple regions is a real incident. For most non-critical monitors, alerting after two failures is the right balance.
Use multi-region confirmation. Nodown only triggers an alert when at least three of its 14 monitoring regions confirm the failure. This eliminates false positives caused by a single monitoring server having a network issue, without adding delay to the detection of real incidents.
Separate alert and recovery notifications. Recovery notifications - "your site is back up, downtime was 4 minutes" - are useful for incident documentation but should not ping the same channel as incident alerts. Route recovery notifications to a lower-priority channel or configure them to post as thread replies on the original alert.
Set quiet hours for non-critical monitors. If a docs site going down at 3am does not require anyone to wake up, configure quiet hours for that monitor. Alerts accumulate and are sent as a digest at the start of the next working day. Critical monitors should never have quiet hours.
Testing your setup before you need it
Do not wait for a real incident to discover your alert configuration is broken.
After connecting Nodown to Slack, use the built-in test button to verify each integration sends to the right channel. Then create a monitor for a URL that does not exist - https://yourdomain.com/this-does-not-exist - and verify that a 404 failure alert appears in the expected Slack channel within the check interval. Delete the test monitor once verified.
Run this test any time you make changes to your alert routing. A monitoring setup you have not tested is a monitoring setup you cannot rely on.
Your Slack integration is one piece of a complete alerting setup. Pair it with an on-call rotation so the right person gets the alert at the right time, and a status page so users are informed while your team investigates.
Connect Nodown to Slack and start monitoring free
Last updated: May 2026.