n8n Tutorial: Build a Multi-Channel Alert System

Missing a critical alert because it only went to one channel is a real operational risk. Slack goes unread. Email gets buried. SMS feels intrusive for low-priority events. The solution is not picking

28 May 2026 — 4 min read

Missing a critical alert because it only went to one channel is a real operational risk. Slack goes unread. Email gets buried. SMS feels intrusive for low-priority events. The solution is not picking the right single channel — it is routing the right alert to the right channel automatically. This tutorial walks through building a multi-channel alert system in n8n that routes notifications based on severity, so your team actually sees what matters.

What You Are Building

A workflow that receives alert events from any source — a monitoring tool, a form submission, a database trigger, a webhook from your app — evaluates the severity of the event, and routes it to the appropriate channel or combination of channels. Low-severity alerts go to Slack. Medium alerts go to Slack and email. High-severity alerts go to Slack, email, and SMS simultaneously. The routing logic lives in n8n, not scattered across three different integrations.

Webhook node as the universal entry point
Switch node for severity-based routing
Slack, Gmail, and Twilio nodes as output channels
Error handling at each channel so one failure does not block others

Setting Up the Webhook Entry Point

Start with a Webhook node set to POST. This becomes your single alert endpoint. Any system that needs to fire an alert sends a JSON payload to this URL. Structure the payload with at minimum three fields: severity (low, medium, high), title, and message. Optionally include source and timestamp for better context in the notifications.

Once the webhook is live, test it with a curl command before wiring up the rest of the workflow. Confirm the payload arrives correctly and n8n can read the fields. This step catches encoding issues early before they surface inside a branching workflow where they are harder to trace.

Set authentication to Header Auth or Basic Auth if this endpoint will be exposed publicly
Use the Respond to Webhook node to send an immediate 200 back so the sending system does not timeout
Log the raw payload to a Google Sheet or Airtable for the first week of operation — invaluable for debugging

Building the Routing Logic with Switch

Add a Switch node after the webhook. Configure it to evaluate {{ $json.severity }} with three output branches: low, medium, high. Each branch connects to a different set of notification nodes. This is the core of the system — everything downstream is just delivery.

One important design decision: use separate execution paths, not a single merged path with conditional sends. This gives you clean error isolation. If the SMS node fails on a high-severity alert, the Slack and email sends have already completed. You are not losing multiple channels because one provider has an outage.

Branch 1 (low): Slack only — post to a #alerts-low channel
Branch 2 (medium): Slack + Gmail — Slack for immediate visibility, email for the audit trail
Branch 3 (high): Slack + Gmail + Twilio SMS — all three fire in parallel using the Merge node set to "Wait for All"

Configuring the Notification Nodes

For Slack, use the Slack node with the "Send Message" operation. Build a structured message using Slack Block Kit rather than plain text — include the severity as a colored header (green, yellow, red), the title, the message body, and the source system. This makes alerts scannable at a glance in a busy channel.

For Gmail, use the Gmail node to send to a distribution list or a specific operations email. Keep the subject line consistent and parseable: [HIGH] Payment processor timeout — 3 consecutive failures. This format makes filtering and searching the inbox trivial six months from now.

For Twilio SMS on high-severity alerts, keep the message under 160 characters. Include severity, a short description, and where to find details. SMS is for interruption — the goal is getting someone to open Slack or email, not delivering the full context in a text.

Store all credentials in n8n's credential manager, not hardcoded in node parameters
Add a try/catch pattern using the Error Trigger node for each channel independently
Consider rate limiting on the webhook if your source system can fire bursts of alerts

Extending the System

Once the core routing is working, two additions make this production-ready. First, add deduplication: store recent alert hashes in a simple key-value store or a Google Sheet and check before sending. Duplicate alerts from flapping systems are one of the fastest ways to make your team start ignoring the alert channel entirely. Second, add an escalation path: if a high-severity alert fires and no acknowledgement comes back within 15 minutes, re-trigger the workflow with an escalation flag that also pages an on-call engineer via PagerDuty or a dedicated escalation Slack DM.

Building this from scratch takes time, but if you want to move faster, browsing ready-made n8n templates can give you a working foundation you modify rather than a blank canvas you build from zero.

Multi-channel alerting is not a complex problem — it is a routing problem. n8n handles routing cleanly once you structure the incoming payload consistently and keep each notification channel in its own execution branch. Build it once, test each severity level end-to-end, and you will spend zero time debugging missed alerts going forward.