n8n Uptime Monitoring with Slack Alerts (Without the Alert Storms)

An Uptime Check That Cries Wolf Gets Muted in a Week

The point of n8n uptime monitoring with Slack alerts isn't to detect a single outage. It's to be trusted the next hundred times it fires. Most of the workflows that rank for this fail that test. They ping one URL, fire on a single failed request, and never send the all-clear. So the channel fills with noise, someone mutes it, and the one real outage goes unnoticed.

The ranking pages get the easy 80% right: Schedule Trigger, HTTP Request, Slack message. They skip the parts that make the difference. Recovery notices. Latency thresholds. SLA history. A debounce so a flapping endpoint doesn't fire twelve times an hour.

n8n is a good fit for this because you own the logic. You decide what "down" means, how long to wait before believing it, and what gets logged for the monthly report.

What You Can Automate in an Uptime Monitor

A monitor worth keeping does more than detect a failed request:

• Multi-endpoint checks: loop a list of URLs through one HTTP Request node instead of one workflow per site
• Status-code branching: treat a 5xx, a redirect loop, and a timeout as different events
• Latency thresholds: alert on a slow-but-200 response, not just on errors
• Debounce: require two consecutive failures before paging, to ignore single transient blips
• Recovery notices: fire a resolved message when a down endpoint returns
• SLA logging: append every check result to Google Sheets so you can compute uptime percentage later
• Alert-storm suppression: don't re-alert every cycle while an endpoint stays down

The Uptime Monitoring Pipeline

Schedule Trigger (every 15 min)
  → Code (load URL list)
  → HTTP Request (per URL, continueOnFail: true, capture status + time)
  → IF (status in 2xx AND time < threshold?)
      → healthy:
          → IF (was previously DOWN?) → Slack (recovery: "X is back up")
          → Google Sheets (append OK + responseTime)
      → unhealthy:
          → Code (increment fail counter for this URL)
          → IF (failCount >= 2 AND not already alerting?)
              → Slack #incidents (down alert + status + last time)
          → Google Sheets (append DOWN + status)

1. Pick the interval deliberately

A Schedule Trigger every 15 minutes catches almost every outage that matters while keeping request volume low. The math is simple: every-minute checks generate 1,440 requests per URL per day against every-15-minute's 96. That's 15x the load, 15x the chances of a transient false positive, and a real risk the run overlaps itself.

In n8n, a Schedule Trigger that fires while the previous execution is still running will silently drop the new run. If your check loop can take longer than the interval (lots of URLs, slow targets), widen the interval or split URLs across staggered workflows.

2. Capture status AND time

Set the HTTP Request node to continue on failure so a dead host doesn't halt the workflow, and grab both signals:

// Code node after HTTP Request — read both health signals
const code = $json.statusCode ?? $json.error?.httpCode ?? 0;
const ms = $json.responseTimeMs ?? 0;
const healthy = code >= 200 && code < 300 && ms < 5000;
return [{ json: { url: $json.url, code, ms, healthy } }];

That 5000ms threshold is a starting point. A marketing page and a checkout API have very different "too slow" lines.

3. Debounce, then alert

The single biggest source of alert-storm noise is firing on the first failed request. Networks blip. Require two consecutive failures for the same URL before paging. Store a per-URL fail counter in a static data store or a Google Sheets column, increment on failure, reset on success.

Then suppress repeats: once you've alerted that an endpoint is down, don't re-alert every 15 minutes. Set an alerting flag and only clear it on recovery. The channel should see one "down" and one "back up," not eight identical alarms.

4. Close the loop with a recovery notice

Track the last state per URL. When a check flips from down to up, fire a resolved message. This is the difference between a monitor people trust and one they learn to ignore. The IF node reads the prior state from Google Sheets and only sends the recovery when the transition actually happens.

5. Log everything for the SLA report

Every result, healthy or not, gets a row: URL, timestamp, status, response time. At month-end a simple formula turns that into an uptime percentage per endpoint. You can't claim a 99.9% SLA without the data behind it, and this is where the data lives.

Implementation Patterns

Pattern 1 — Two consecutive failures before paging. A single failed request is noise more often than it's an outage. The AI Ops Watchtower template builds in this debounce plus the recovery notice, so the channel only sees real state changes.

HTTP Request (fail) → Code (failCount++) → IF (failCount >= 2) → Slack

Pattern 2 — Separate the "slow" alert from the "down" alert. A degraded service and a dead one need different responses. Branch latency and status independently and label them. On-call should know at a glance whether to roll back or just watch.

IF (code in 2xx) → IF (ms > threshold) → Slack #perf (degraded, not down)

Pattern 3 — One workflow, many URLs. Loop a maintained list through a single HTTP Request node. Adding a site is a row edit, not a new workflow.

n8n Nodes You'll Use Most

Getting Started

1. Add a Schedule Trigger and set it to every 15 minutes.
2. Load your URL list (a Code node or a Google Sheets read).
3. Add an HTTP Request node with continue-on-fail, capturing status and time.
4. Add the health-check Code node and the debounce counter.
5. Wire the recovery IF branch off the last-known state.
6. Append every result to Google Sheets for SLA reporting.
7. Send alerts to Slack, then start from a template rather than rebuilding the debounce logic by hand.

If your alerts need to reach a phone instead of a channel, the routing pattern in n8n Telegram automation covers the same idea with a different destination. For deploy-time failures rather than uptime, the AI Ops Guard for No-Code Agents template handles CI events with the same alert discipline, and for the broader incident-response picture, automating DevOps workflows with n8n connects uptime monitoring to on-call escalation.