Die meisten Teams erfahren von einem Problem nicht aus einem Dashboard, sondern vom Kunden. Der Lagerbestand stand stundenlang auf null, bevor jemand in die ERP-Maske geschaut hat. Der Server war seit dem Morgen nicht erreichbar, aber der Anruf kam erst mittags. Das ist selten ein Technikproblem. Es ist ein Lückenproblem: Niemand hat den Moment definiert, in dem ein Zustand laut werden soll.
Genau diese Lücke schließt Alarmierung mit n8n, ohne eine Zeile klassischen Codes und ohne ein dediziertes Monitoring-Team. Du baust eine Kette aus drei Bausteinen: etwas löst aus, eine Bedingung entscheidet, ein Kanal benachrichtigt. Dieser Artikel zeigt die Kette Schritt für Schritt, von der ersten Slack-Nachricht bei niedrigem Lagerbestand bis zu dem Alarm, den fast alle vergessen: dem über die Automatisierung, die selbst stillschweigend ausgefallen ist.
Was Alarmierung mit n8n eigentlich heißt
Bevor wir klicken: Eine Alarmierung ist kein Werkzeug, sondern ein Muster. In n8n besteht jede Benachrichtigung aus denselben drei Teilen, und wenn du das Muster einmal verstanden hast, baust du jeden weiteren Alarm in Minuten.
Der Auslöser (Trigger) bestimmt, wann n8n hinschaut. Bei der Schwellwert-Überwachung ist das meist ein Zeitplan: alle fünf Minuten, stündlich, jeden Morgen um sieben. Bei einem Echtzeit-Ereignis ist es ein Webhook, den ein anderes System anstößt. Die Bedingung entscheidet, ob überhaupt etwas Ungewöhnliches vorliegt: Bestand unter zehn, HTTP-Status nicht 200, Umsatz unter Plan. Dafür gibt es in n8n den IF-Knoten. Und der Kanal legt fest, wer es wie erfährt: eine Slack-Nachricht ins Team, eine E-Mail an die Buchhaltung, eine SMS auf das Diensthandy.
Kurz gesagt: Auslöser, Bedingung, Kanal. Alles, was folgt, sind Varianten dieser drei Knoten. Der häufigste Anfängerfehler ist, die Bedingung wegzulassen und bei jedem Durchlauf eine Nachricht zu schicken. Dann hast du keinen Alarm, sondern ein Rauschen, das nach drei Tagen niemand mehr liest.
Schritt für Schritt: deine erste Alarmierung
Nehmen wir den klassischen Fall: Der Lagerbestand eines Artikels soll nicht unbemerkt unter zehn Stück fallen. Vier Knoten genügen.
1. Schedule Trigger. Lege einen Schedule-Trigger an und stelle ihn auf alle 15 Minuten. Der Schedule-Trigger ist einer der am häufigsten genutzten Auslöser in produktiven n8n-Setups, weil die meisten Überwachungen genau so funktionieren: regelmäßig nachsehen, statt auf ein Ereignis zu warten.
2. Daten holen. Häng einen HTTP-Request- oder Datenbank-Knoten an, der den aktuellen Bestand liefert, etwa aus deiner ERP-API oder direkt per SQL aus der Warenwirtschaft. Das Ergebnis landet als JSON im Workflow, zum Beispiel so:
{
"artikel": "NL-2026-Hoodie-L",
"bestand": 7,
"schwelle": 10
}
3. IF-Knoten. Jetzt die Bedingung. Im IF-Knoten vergleichst du das Feld bestand mit deiner Schwelle. Als n8n-Expression sieht die linke Seite so aus:
{{ $json.bestand }}
Operator „kleiner als", Vergleichswert 10. Liegt der Bestand darunter, läuft der Workflow über den „true"-Ausgang weiter, sonst passiert nichts, und genau das ist gewollt. Ein Detail, das Anfänger gern stolpern lässt: n8n vergleicht standardmäßig typgenau. Kommt bestand als Text "7" statt als Zahl 7 aus dem vorherigen Knoten, greift „kleiner als" nicht. Im Zweifel den Wert vorher in eine Zahl wandeln.
4. Slack-Knoten. An den „true"-Zweig hängst du einen Slack-Knoten mit der Operation „Send a Message". In den Nachrichtentext kommen die echten Werte direkt aus dem JSON:
⚠️ Bestand niedrig: {{ $json.artikel }} hat nur noch
{{ $json.bestand }} Stück (Schwelle: {{ $json.schwelle }}).
Fertig. Vier Knoten, ein produktiver Alarm. Aktivierst du den Workflow, prüft n8n ab jetzt alle 15 Minuten und meldet sich nur, wenn es etwas zu melden gibt. Dasselbe Gerüst trägt jede Schwellwert-Überwachung. Du tauschst nur die Datenquelle und die Bedingung: offene Tickets über 50, Festplattenbelegung über 90 Prozent, Tagesumsatz unter dem Soll von 5.000 Euro bis 14 Uhr.
Die drei Auslöser-Typen und wann du welchen nimmst
Der Schedule-Trigger deckt fast alles ab, was „regelmäßig nachsehen" heißt. Aber es gibt zwei weitere Auslöser, die zusammen die anderen beiden Drittel der realen Alarmierungsfälle abdecken.
Der Webhook-Trigger gibt deinem Workflow eine eigene URL. Schickt ein externes System einen POST- oder GET-Request an diese URL, feuert der Workflow sofort, mit den übergebenen Daten als Eingabe. Den brauchst du, wenn ein Ereignis nicht warten kann, bis der nächste Zeitplan greift. Konkret: Dein Shop ruft die Webhook-URL auf, sobald eine Zahlung fehlschlägt, und n8n pingt binnen Sekunden den zuständigen Mitarbeiter im richtigen Slack-Kanal. Oder eine Maschinensteuerung meldet einen kritischen Statuscode, und der Webhook löst aus, bevor jemand auf das nächste Stundenintervall warten müsste. Faustregel: Zustände pollst du per Zeitplan, Ereignisse empfängst du per Webhook.
Der dritte Auslöser ist der Error-Trigger, und der ist wichtig genug für einen eigenen Abschnitt weiter unten, denn er überwacht nicht dein Geschäft, sondern deine Automatisierungen selbst.
Kanäle: Slack, E-Mail oder SMS
Welcher Kanal richtig ist, hängt nicht vom Geschmack ab, sondern von der Dringlichkeit und davon, wo die Empfänger ohnehin schon hinschauen.
Slack (oder Microsoft Teams) ist der Standard für alles, was ein Team betrifft und während der Arbeitszeit relevant ist. Der Slack-Knoten postet in einen Kanal oder als Direktnachricht; für echte Eskalation kannst du im Text gezielt eine Person mit @ erwähnen, statt den ganzen Kanal zu pingen. E-Mail über den Send-Email- oder SMTP-Knoten passt, wenn der Alarm dokumentiert werden oder eine Person außerhalb des Chat-Tools erreichen soll: die Buchhaltung, einen externen Dienstleister, ein Ticketsystem, das auf eingehende Mails hört. SMS über den Twilio-Knoten ist der teuerste und gleichzeitig zuverlässigste Kanal. Sie kommt auch dann an, wenn niemand Slack offen hat, nachts, am Wochenende, beim Produktionsausfall. Genau deshalb gehört sie nur an die wenigen Alarme, die wirklich jemanden aus dem Feierabend holen dürfen.
In der Praxis kombinierst du. Eine saubere Regel: unkritische Hinweise nach Slack, kritische zusätzlich per SMS. Den Unterschied entscheidest du nicht im Kanal, sondern eine Stufe vorher, über die Schwere des Alarms.
Der Alarm, den fast alle vergessen: ausgefallene Workflows
Hier liegt der häufigste blinde Fleck. Du hast deine Bestandsüberwachung gebaut, sie läuft, du fühlst dich abgesichert. Drei Wochen später stellst du fest, dass die ERP-API ihr Token rotiert hat und der Workflow seit zwölf Tagen bei jedem Lauf abbricht. Es kam nie ein Alarm, weil der Alarm selbst der ausgefallene Teil war.
n8n löst das mit einem eigenen Mechanismus. Du baust einen zentralen Fehler-Workflow, der mit dem Error-Trigger-Knoten beginnt. Dieser Knoten reagiert nicht auf ein externes Ereignis, sondern feuert, sobald irgendein anderer Workflow in deiner Instanz scheitert. Dahinter hängst du wieder einen Kanal, typischerweise Slack. In den Einstellungen jedes produktiven Workflows trägst du diesen Fehler-Workflow dann unter „Error Workflow" ein. Ab da meldet sich n8n von selbst, wenn etwas bricht.
Der Clou: Der Error-Trigger liefert den Kontext gleich mit. Name des betroffenen Workflows, Ausführungs-ID, Zeitstempel und ein direkter Link zur fehlgeschlagenen Ausführung, sofern n8n die Ausführung gespeichert hat (bei einem Fehler bereits im Trigger-Knoten des Haupt-Workflows fehlt der Link, weil keine Ausführung entsteht). Im Normalfall landest du mit einem Klick aus der Slack-Nachricht genau in der Execution, die schiefging, und siehst, welcher Knoten den Fehler geworfen hat. Diesen einen Fehler-Workflow baust du einmal und hängst jeden weiteren produktiven Workflow daran. Es ist die fünf Minuten gut investierte Arbeit, die den Unterschied zwischen „wir überwachen" und „wir glauben, wir überwachen" ausmacht.
Alarm-Müdigkeit vermeiden
Ein Alarmsystem scheitert selten daran, dass es zu wenig meldet. Es scheitert daran, dass es zu viel meldet und deshalb ignoriert wird. Wenn dein Slack-Kanal alle zehn Minuten piept, hat der erste echte Notfall dieselbe Chance, gesehen zu werden, wie das Hintergrundrauschen davor, nämlich keine.
Drei Hebel halten das System leise genug, um ernst genommen zu werden. Erstens Schweregrade: Klassifiziere in einem Code- oder Set-Knoten zwischen WARNUNG und KRITISCH. Kritisches (Authentifizierung kaputt, Datenverlust droht) geht sofort raus, idealerweise zusätzlich per SMS; Warnungen sammelst du. Zweitens Bündelung: Statt 60 einzelne Niedrigbestand-Hinweise über den Tag zu verschicken, sammelst du sie und schickst um acht Uhr morgens eine Digest-Nachricht mit allen offenen Fällen in einer Liste. Aus 60 Pings wird eine Nachricht, die jemand tatsächlich liest. Drittens Entprellung: Ein Zustand, der zehnmal hintereinander dieselbe Bedingung erfüllt, soll nicht zehn Alarme erzeugen. Merke dir den letzten gemeldeten Zustand und schick nur dann erneut, wenn er sich geändert hat.
Diese drei Regeln sind der Unterschied zwischen einem Alarmsystem, dem das Team vertraut, und einem, das nach zwei Wochen stummgeschaltet wird. Wer Prozessautomatisierung ernst betreibt, plant sie von Anfang an mit ein. In unserer Prozessautomatisierung mit KI-Workflows ist diese Disziplin fester Bestandteil jedes Setups, kein Nachgedanke.
Wo n8n als Alarmierung an seine Grenzen kommt
Eine ehrliche Eingrenzung gehört dazu, sonst baust du auf das falsche Werkzeug. n8n ist hervorragend als Klebeschicht zwischen Systemen: Es löst aus, prüft, benachrichtigt und verbindet Quellen, die sonst nichts voneinander wissen. Was n8n nicht ist: eine vollwertige Monitoring- oder On-Call-Plattform.
Wenn du Server-Infrastruktur im Sekundentakt mit Metriken, Histogrammen und Alarm-Regeln überwachen willst, sind Prometheus und Grafana das richtige Werkzeug. Wenn du echte Bereitschaftsdienste mit Eskalationsketten, Schichtplänen und Bestätigungspflicht brauchst, gehört das zu PagerDuty oder Opsgenie. n8n kann diese Spezialwerkzeuge anstoßen und ihre Alarme in deine Kanäle übersetzen, aber es ersetzt sie nicht. Der Bereich, in dem n8n unschlagbar ist, liegt dazwischen: geschäftsnahe Zustände, die in keinem klassischen Monitoring auftauchen, weil sie aus deinem ERP, deinem Shop oder deiner Tabelle kommen. Genau dort, wo bisher jemand „mal eben nachsehen" musste, setzt die Alarmierung mit n8n an.
Wenn du n8n breiter als nur für Alarme einsetzen willst, lohnt der Blick auf die sieben Workflows, die sich im Mittelstand am schnellsten rechnen; Alarmierung ist nur einer davon. Und wenn die ersten Workflows produktiv tragen sollen, ohne dass du dir die Stolperfallen einzeln erarbeitest, rechnet sich eine begleitete KI- und Prozessautomatisierung oft schneller als das Selbststudium.
Fazit
Alarmierung mit n8n ist kein großes Projekt, sondern ein wiederkehrendes Muster aus drei Knoten: Auslöser, Bedingung, Kanal. Die erste produktive Benachrichtigung steht in einer Viertelstunde, und ab da ist jeder weitere Alarm eine Variation desselben Gerüsts. Drei Dinge entscheiden, ob das System trägt: dass es eine echte Bedingung hat statt blind zu feuern, dass es sich über seine eigenen Ausfälle selbst meldet, und dass es leise genug bleibt, um ernst genommen zu werden. Bau den ersten Alarm heute, häng den Fehler-Workflow dahinter, und das nächste Problem erfährst du aus n8n, nicht vom Kunden.