Most teams do not learn about a problem from a dashboard, but from the customer. Stock was at zero for hours before anyone looked at the ERP screen. The server had been unreachable since the morning, but the call only came at midday. That is rarely a technology problem. It is a gap problem: nobody has defined the moment at which a state should make itself heard.
This is exactly the gap that alerting with n8n closes, without a line of classic code and without a dedicated monitoring team. You build a chain of three building blocks: something triggers, a condition decides, a channel notifies. This article shows the chain step by step, from the first Slack message when stock is low to the alert that almost everyone forgets: the one about the automation that has itself silently failed.
What alerting with n8n actually means
Before we start clicking: alerting is not a tool but a pattern. In n8n, every notification consists of the same three parts, and once you have understood the pattern, you can build any further alert in minutes.
The trigger determines when n8n takes a look. For threshold monitoring, this is usually a schedule: every five minutes, every hour, every morning at seven. For a real-time event, it is a webhook that another system calls. The condition decides whether anything unusual is happening at all: stock below ten, HTTP status not 200, revenue below plan. n8n has the IF node for this. And the channel determines who finds out and how: a Slack message to the team, an email to accounts, an SMS to the work phone.
In short: trigger, condition, channel. Everything that follows is a variation of these three nodes. The most common beginner’s mistake is to leave out the condition and send a message on every run. Then you do not have an alert but noise that nobody reads any more after three days.
Step by step: your first alert
Let us take the classic case: the stock of an item should not fall below ten units unnoticed. Four nodes are enough.
1. Schedule Trigger. Create a Schedule Trigger and set it to every 15 minutes. The Schedule Trigger is one of the most frequently used triggers in production n8n set-ups, because most monitoring works exactly like this: checking regularly instead of waiting for an event.
2. Fetch the data. Attach an HTTP Request or database node that returns the current stock level, for example from your ERP API or directly via SQL from your inventory management system. The result lands in the workflow as JSON, for example like this:
{
"item": "NL-2026-Hoodie-L",
"stock": 7,
"threshold": 10
}
3. IF node. Now the condition. In the IF node you compare the field stock with your threshold. As an n8n expression, the left-hand side looks like this:
{{ $json.stock }}
Operator ‘is less than’, comparison value 10. If the stock is below it, the workflow continues via the ‘true’ output; otherwise nothing happens, and that is exactly what is intended. One detail that often trips up beginners: by default, n8n compares strictly by type. If stock comes out of the previous node as the text "7" instead of the number 7, ‘is less than’ does not match. If in doubt, convert the value to a number beforehand.
4. Slack node. To the ‘true’ branch you attach a Slack node with the operation ‘Send a Message’. The message text takes the real values directly from the JSON:
⚠️ Low stock: {{ $json.item }} only has
{{ $json.stock }} units left (threshold: {{ $json.threshold }}).
Done. Four nodes, one production-ready alert. Once you activate the workflow, n8n checks every 15 minutes from now on and only reports when there is something to report. The same framework carries any threshold monitoring. You only swap the data source and the condition: open tickets above 50, disk usage above 90 per cent, daily revenue below the target of 5,000 euros by 2 pm.
The three trigger types and when to use which
The Schedule Trigger covers almost everything that means ‘checking regularly’. But there are two more triggers that together cover the other two thirds of real-world alerting cases.
The Webhook trigger gives your workflow its own URL. If an external system sends a POST or GET request to this URL, the workflow fires immediately, with the data passed as input. You need it when an event cannot wait until the next schedule kicks in. Specifically: your shop calls the webhook URL as soon as a payment fails, and within seconds n8n pings the responsible employee in the right Slack channel. Or a machine controller reports a critical status code, and the webhook fires before anyone would have to wait for the next hourly interval. Rule of thumb: you poll states on a schedule, you receive events via webhook.
The third trigger is the Error Trigger, and it is important enough for its own section further down, because it does not monitor your business but your automations themselves.
Channels: Slack, email or SMS
Which channel is right does not depend on taste, but on urgency and on where the recipients are already looking anyway.
Slack (or Microsoft Teams) is the standard for anything that affects a team and is relevant during working hours. The Slack node posts to a channel or as a direct message; for a real escalation, you can mention a specific person in the text with @ instead of pinging the whole channel. Email via the Send Email or SMTP node fits when the alert needs to be documented or should reach a person outside the chat tool: accounts, an external service provider, a ticket system that listens for incoming emails. SMS via the Twilio node is the most expensive and at the same time the most reliable channel. It arrives even when nobody has Slack open: at night, at the weekend, during a production outage. That is exactly why it belongs only on the few alerts that are really allowed to pull someone away from their evening off.
In practice you combine them. A clean rule: non-critical notices go to Slack, critical ones additionally by SMS. You do not decide the difference in the channel, but one step earlier, via the severity of the alert.
The alert almost everyone forgets: failed workflows
This is where the most common blind spot lies. You have built your stock monitoring, it is running, you feel safe. Three weeks later you discover that the ERP API has rotated its token and the workflow has been aborting on every run for twelve days. No alert ever came, because the alert itself was the part that had failed.
n8n solves this with a mechanism of its own. You build one central error workflow that starts with the Error Trigger node. This node does not react to an external event, but fires as soon as any other workflow in your instance fails. Behind it you again attach a channel, typically Slack. In the settings of every production workflow, you then enter this error workflow under ‘Error Workflow’. From then on, n8n reports on its own when something breaks.
The clever part: the Error Trigger delivers the context along with it. The name of the affected workflow, the execution ID, a timestamp and a direct link to the failed execution, provided n8n has saved the execution (if the error occurs in the trigger node of the main workflow, the link is missing because no execution is created). Normally, one click from the Slack message takes you straight to the execution that went wrong, and you can see which node threw the error. You build this one error workflow once and attach every further production workflow to it. It is five minutes of well-invested work that makes the difference between ‘we are monitoring’ and ‘we think we are monitoring’.
Avoiding alert fatigue
An alerting system rarely fails because it reports too little. It fails because it reports too much and is therefore ignored. If your Slack channel beeps every ten minutes, the first real emergency has the same chance of being seen as the background noise before it, namely none.
Three levers keep the system quiet enough to be taken seriously. First, severity levels: In a Code or Set node, classify between WARNING and CRITICAL. Critical issues (authentication broken, data loss imminent) go out immediately, ideally by SMS as well; warnings are collected. Second, bundling: Instead of sending 60 individual low-stock notices over the course of the day, you collect them and send a digest message at eight in the morning with all open cases in one list. 60 pings become one message that someone actually reads. Third, debouncing: A state that meets the same condition ten times in a row should not generate ten alerts. Remember the last reported state and only send again if it has changed.
These three rules are the difference between an alerting system that the team trusts and one that is muted after two weeks. Anyone who takes process automation seriously plans them in from the start. In our process automation with AI workflows, this discipline is an integral part of every set-up, not an afterthought.
Where n8n reaches its limits for alerting
An honest limitation is part of it, otherwise you build on the wrong tool. n8n is excellent as a glue layer between systems: it triggers, checks, notifies and connects sources that otherwise know nothing about each other. What n8n is not: a full-fledged monitoring or on-call platform.
If you want to monitor server infrastructure second by second with metrics, histograms and alerting rules, Prometheus and Grafana are the right tools. If you need real on-call duty with escalation chains, shift schedules and mandatory acknowledgement, that belongs in PagerDuty or Opsgenie. n8n can trigger these specialist tools and translate their alerts into your channels, but it does not replace them. The area in which n8n is unbeatable lies in between: business-related states that do not show up in any classic monitoring because they come from your ERP, your shop or your spreadsheet. Exactly where someone previously had to ‘just quickly check’, alerting with n8n comes in.
If you want to use n8n more broadly than just for alerts, it is worth looking at the seven workflows that pay off fastest in SMEs; alerting is only one of them. And if the first workflows are to run reliably in production without you having to work out the pitfalls one by one, guided AI and process automation often pays off faster than teaching yourself.
Conclusion
Alerting with n8n is not a big project but a recurring pattern of three nodes: trigger, condition, channel. The first production notification is up and running in a quarter of an hour, and from then on every further alert is a variation of the same framework. Three things decide whether the system holds up: that it has a real condition instead of firing blindly, that it reports its own failures, and that it stays quiet enough to be taken seriously. Build the first alert today, put the error workflow behind it, and you will learn about the next problem from n8n, not from the customer.