Build an n8n Service Health Monitor with Double-Verification & Slack Alerts

If you're running web services, APIs, or internal tools, you need to know the moment they go down — but you also don't want to be woken up at 3 AM by a false alarm. Building an n8n service health monitor with double-verification and Slack alerts solves exactly that problem. This workflow checks your endpoints on a schedule, performs a second verification before raising the alarm, and sends confirmed failure alerts to Slack (or email, SMS, or any channel you prefer). And because you're running it on n8nautomation.cloud, it stays up 24/7 without you managing a single server.

Why Double-Verification Matters

Single-check monitoring is noisy. A momentary network blip, a slow response during a deployment, or a CDN hiccup can all trigger a false alert. Double-verification means the workflow waits a short interval, then checks the service again before declaring it down. This simple pattern eliminates 90% of false positives.

Here is what the complete workflow does:

• Pings your service endpoint on a configurable schedule (every 5, 15, or 60 minutes).
• Checks the HTTP status code and response time.
• If the service is down, waits 60 seconds and retries once.
• Only sends a Slack alert if the second verification also fails.
• Logs every check for later analysis.

This pattern is production-tested at scale. The workflow from the n8n community (workflow #8130) uses this exact approach, and it is one of the most popular monitoring templates available.

What You Will Build

You will create a single n8n workflow with five nodes. No custom code is required — everything runs through native n8n nodes. The workflow takes about 20 minutes to set up, even if you are new to n8n.

Here are the nodes you will use:

• Schedule Trigger — runs the check on a cron interval.
• HTTP Request — pings your service endpoint.
• IF — evaluates the HTTP status code (200 = up, anything else = down).
• Wait — pauses 60 seconds for the second verification.
• HTTP Request (second) — retries the endpoint.
• IF (second) — checks the retry result.
• Slack — sends a message if both checks fail.
• NoOp — a clean ending for the "service is up" path.

Step-by-Step Workflow Setup

Follow these steps to build the service health monitor from scratch. All node names match the default labels in n8n's editor.

1. Add a Schedule Trigger node.
   • Set the trigger mode to Cron Expression.
   • Enter */5 * * * * to check every 5 minutes.
   • For less frequent checks, use */15 * * * * (15 minutes) or 0 * * * * (every hour).
2. Add an HTTP Request node.
   • Set Method to GET.
   • Enter your service URL in the URL field (e.g., https://your-app.com/health).
   • Enable Response Format and set it to Response to capture the full HTTP response.
3. Add an IF node.
   • Connect it to the HTTP Request node.
   • Set the condition: {{ $json.statusCode }} equals 200.
   • If true (service is up), route to the NoOp node or do nothing.
   • If false (service is down), route to the Wait node.
4. Add a Wait node.
   • Set Wait Type to Duration.
   • Set Amount to 60 and Unit to Seconds.
   • This 60-second pause is the core of the double-verification pattern.
5. Add a second HTTP Request node.
   • Connect it after the Wait node.
   • Use the same URL and method as the first request.
6. Add a second IF node.
   • Same condition: {{ $json.statusCode }} equals 200.
   • If true (service recovered after 60 seconds), route to NoOp — no alert needed.
   • If false (service is still down), route to the Slack node.
7. Add a Slack node.
   • Connect a Slack credential (you need a Slack workspace and an incoming webhook URL).
   • Set Channel to #alerts or your preferred channel.
   • Compose a message like: 🚨 Service DOWN: {{ $node["HTTP Request"].json.url }} returned status {{ $node["HTTP Request"].json.statusCode }} after two checks.
8. Save and activate the workflow.
   • Toggle the Active switch in the top-right corner.
   • n8n will now run this workflow on your schedule automatically.

Expanding the Monitor with Multi-Channel Alerts

A single Slack alert is a good start, but production monitoring needs redundancy. If your team does not check Slack during weekends, or if Slack itself goes down, you need a fallback. The n8n community workflow #10348 demonstrates this pattern with AWS EC2 instances — you can adapt it for any service.

Here is how to add multi-channel alerts:

1. Add an Email node after the second IF node, parallel to the Slack node.
   • Use the SMTP credential with your email provider (Gmail, SendGrid, or your own SMTP server).
   • Send to an on-call engineer's email or a team mailing list.
2. Add a Telegram node for instant mobile notifications.
   • Create a Telegram bot and get the chat ID.
   • Send a message with the same alert details.
3. Add a PagerDuty or Opsgenie node (if you use incident management tools).
   • n8n has native nodes for both platforms.
   • This triggers on-call rotations and escalation policies automatically.

You can also log every check to a Google Sheet or a database for historical analysis. This helps you spot trends — like a service that gets slower every Wednesday afternoon — before they become outages.

Hosting Considerations for Monitoring Workflows

A monitoring workflow is only as reliable as the server running it. If your n8n instance goes down, your monitoring goes down with it — and you will not know about it. This is one of the strongest arguments for using managed n8n hosting instead of self-hosting.

Here are the key hosting requirements for a production monitoring setup:

• 99.9% uptime or better — your monitor must outlive the services it watches. A managed n8n instance with automatic failover ensures your Schedule Trigger never misses a beat.
• Automatic backups — if you update the workflow and break it, you need to roll back instantly. Managed hosting platforms like n8nautomation.cloud handle this automatically.
• Instance logs — when the workflow behaves unexpectedly (e.g., it stops sending alerts), you need to see why. The n8n Logs viewer in the dashboard gives you execution logs without SSH access.
• Resource isolation — a dedicated instance means your monitoring workflow is not competing for CPU or memory with someone else's data pipelines.

Monitoring SSL Certificates and Expiry Dates

Service health monitoring is not just about HTTP status codes. SSL certificates expire, and when they do, your users see browser warnings. You can extend the same workflow to check certificate expiry dates.

Here is a simple approach using the Code node:

1. Replace the HTTP Request node with a Code node that uses Node.js to fetch the SSL certificate.
   • Use the https and tls modules built into Node.js.
   • Extract the valid_to date from the certificate.
2. Calculate days until expiry in the same Code node.
   • Subtract the current date from valid_to.
   • Return the number of days remaining.
3. Add an IF node that checks if days remaining is less than 14.
   • If true, send a Slack alert: ⚠️ SSL certificate for your-app.com expires in 10 days.
   • If false, do nothing — the certificate is still healthy.

This pattern is used by the LinkedIn post from the search results (Ali Haider's automated SSL monitoring setup). It is a lightweight, no-cost addition to your existing health monitor.

Real-World Example: Healthcare and Compliance

The search results also highlight a growing use case: n8n AI automation for healthcare workflows. In regulated industries, monitoring is not optional — it is a compliance requirement. If a patient portal or EHR integration goes down, you need documented proof of detection and response times.

Your n8n health monitor can serve as that audit trail:

• Every check is logged in the n8n execution history.
• Every alert includes a timestamp, status code, and response time.
• You can export these logs for compliance reviews.

This is far more reliable than relying on third-party uptime monitors that may not cover your specific API endpoints or internal services.

Next Steps: Extending Your Monitoring Stack

Once you have the basic health monitor running, you can extend it in several directions:

• Monitor multiple services — duplicate the workflow and change the URL for each service you want to watch.
• Track response time trends — log response times to a database and build a dashboard with the n8n HTTP Request node hitting a charting API.
• Auto-heal with webhooks — when a service fails, trigger a webhook that restarts a container or calls a deployment pipeline. The AWS EC2 auto-heal workflow (#10348) is a perfect example of this pattern.
• Integrate with AI agents — the n8n community has built AI-agent-based decision flows that evaluate alerts and decide whether to notify a human, restart a service, or escalate. This is the future of incident management.

Building your own service health monitor in n8n takes less than 30 minutes, costs nothing beyond your hosting plan, and gives you complete control over what gets monitored, how alerts are verified, and where they are sent. With a managed instance on n8nautomation.cloud, you can set it up instantly and trust it to run 24/7 without server maintenance.