Alarmierung mit n8n: Monitoring und Benachrichtigungen, die niemand verschläft

Ein Datenimport bricht nachts um zwei ab, die Schnittstelle zur Warenwirtschaft liefert nur noch Fehlermeldungen, und niemand merkt es bis zum nächsten Morgen. Der Schaden entsteht selten durch den Fehler selbst, sondern durch die Stunden, in denen ihn niemand bemerkt. Genau hier setzt Alarmierung mit n8n an: Störungen erkennen und auf immer dringlicheren Kanälen melden, bis jemand reagiert.

Eine Alarmierung mit n8n besteht aus drei Teilen: einem Trigger, der den Fehler bemerkt (Error Trigger, Schedule Trigger oder Webhook), einer Prüf-Logik, die entscheidet, ob und wie dringend alarmiert wird, und Benachrichtigungs-Knoten für E-Mail, Microsoft Teams, SMS oder Telefonanruf. Reagiert innerhalb einer definierten Zeit niemand, schaltet der Workflow auf die nächste Eskalationsstufe.

Warum Alarmierung der unterschätzte n8n-Anwendungsfall ist

Die meisten Unternehmen setzen n8n für Datenabgleich und Prozessautomatisierung ein, dabei ist Monitoring einer der Anwendungsfälle mit dem schnellsten Nutzen. Spezialisierte Alarmierungsdienste rechnen pro Nutzer und Monat ab und sind für ein kleines Team oft überdimensioniert. Mit n8n nutzen Sie ein Werkzeug, das viele Betriebe ohnehin schon betreiben, und behalten die Alarmlogik im eigenen Haus: Wer wann worüber benachrichtigt wird, steht in einem Workflow, den Sie selbst lesen und ändern können.

Das Muster passt auf fast jedes System mit Schnittstelle: Onlineshop, Warenwirtschaft, Backupserver, Website-Formulare. Weitere Beispiele aus der Praxis finden Sie in unseren Anwendungsfällen.

Die Bausteine: Trigger, Prüf-Logik, Kanäle

Jede Alarmierung in n8n beginnt mit einem von drei Trigger-Typen, die festlegen, wie ein Problem überhaupt bemerkt wird:

• Error Trigger: startet einen eigenen Fehler-Workflow, sobald ein anderer n8n-Workflow fehlschlägt. Er wird in den Einstellungen des überwachten Workflows als Error Workflow hinterlegt und erhält Details zur fehlgeschlagenen Ausführung.
• Schedule Trigger: läuft nach Intervall oder Cron-Ausdruck, etwa alle fünf Minuten, und prüft aktiv, ob ein System antwortet, ein Backup existiert oder ein Grenzwert überschritten ist.
• Webhook: nimmt Meldungen von außen entgegen, etwa von einem Server-Monitoring oder einer Anwendung, die selbst Alarme senden kann.

Nach dem Trigger folgt die Prüf-Logik, meist ein IF- oder Switch-Knoten: Ist der Fehler kritisch oder nur ein Hinweis? Ist gerade Arbeitszeit oder Wochenende? Erst danach kommen die Kanäle. n8n bringt fertige Knoten für E-Mail, Microsoft Teams und Slack mit; SMS und Telefonanrufe laufen über Dienste wie Twilio oder sipgate per API. Ein ernster Alarm gehört auf einen Kanal, der auch nachts wach macht.

Wie wir solche Workflows für Betriebe aufsetzen und betreiben, zeigt unsere Leistungsseite zu n8n-Automatisierung.

Eine Eskalationskette, Schritt für Schritt

Eine typische Eskalationskette hat drei Stufen und braucht in n8n nur einen einzigen Workflow. Stufe eins: Der Error Trigger feuert, der Workflow formatiert die Fehlermeldung und postet sie in einen Teams-Kanal, zusammen mit einem Quittier-Link. Dieser Link zeigt auf einen Webhook, der die Meldung als übernommen markiert. Stufe zwei: Ein Wait-Knoten pausiert den Workflow, zum Beispiel 15 Minuten. Wurde bis dahin nicht quittiert, geht eine E-Mail an die Teamleitung, wieder mit Quittier-Link. Stufe drei: Nach weiteren 15 Minuten ohne Reaktion löst der Workflow eine SMS oder einen Telefonanruf an die Bereitschaft aus.

Wichtig ist die Quittierung. Ohne sie eskaliert entweder alles bis zum Anruf, oder die Kette bricht nach der ersten Nachricht ab und niemand weiß, ob sich jemand kümmert. Wer wann übernommen hat, steht mit Quittier-Webhook im Ausführungsprotokoll.

Selbstüberwachung: Wer alarmiert, wenn n8n selbst steht

Ein Monitoring, das sich nicht selbst überwacht, hat einen blinden Fleck: Steht der n8n-Server, feuert auch kein Error Trigger mehr. Die Lösung ist ein Heartbeat, im Englischen auch Dead Man's Switch genannt. Ein kleiner Workflow mit Schedule Trigger meldet sich alle paar Minuten bei einem externen Prüfdienst wie Healthchecks.io oder einem selbst gehosteten Uptime Kuma. Bleibt das Lebenszeichen aus, schlägt der externe Dienst Alarm, unabhängig davon, was mit n8n passiert ist. So überwachen sich beide Systeme gegenseitig.

Typische Fehler bei der Alarmierung mit n8n

Die häufigsten Fehler bei der Alarmierung mit n8n sind keine technischen, sondern konzeptionelle. Diese fünf sehen wir in der Praxis immer wieder:

• Alles alarmiert: Wenn jede Kleinigkeit eine Nachricht auslöst, stumpfen alle ab und der eine wichtige Alarm geht unter. Erst priorisieren, dann benachrichtigen.
• Error Workflow nicht zugewiesen: Der Fehler-Workflow existiert, ist aber in den Einstellungen der überwachten Workflows nicht als Error Workflow hinterlegt. Dann passiert im Fehlerfall nichts.
• Nur manuell getestet: Laut n8n-Dokumentation läuft der Error Trigger nur bei automatischen Ausführungen, nicht bei manuellen Testläufen. Wer nur manuell testet, hält seine Alarmierung fälschlich für funktionsfähig.
• Nur ein Kanal: Läuft die Alarmierung ausschließlich über Teams, fällt sie mit aus, wenn Microsoft 365 gestört ist. Mindestens ein Kanal sollte unabhängig sein, etwa SMS.
• Keine Selbstüberwachung: Ohne Heartbeat merkt niemand, wenn der Wächter selbst ausfällt.

Dazu kommt ein organisatorischer Punkt: Eine Eskalationskette braucht Menschen, die am Ende abheben. Klären Sie vor dem Bau, wer Bereitschaft hat. Die Technik ist der einfachere Teil.

Häufige Fragen

Was ist der Error Trigger in n8n?

Der Error Trigger ist ein Knoten, der einen eigenen Fehler-Workflow startet, sobald ein damit verknüpfter Workflow fehlschlägt. Er erhält Details zur fehlgeschlagenen Ausführung, etwa Workflow-Name und Fehlermeldung, und wird in den Einstellungen des überwachten Workflows unter Error Workflow zugewiesen. Mit dem Knoten Stop And Error lassen sich zusätzlich eigene Fehler auslösen.

Kann n8n bei einem Fehler automatisch anrufen?

Ja, über Telefonie-Dienste mit API wie Twilio oder sipgate. Der n8n-Workflow ruft die Schnittstelle des Anbieters auf und löst damit eine SMS oder einen Sprachanruf mit Ansage aus. Für gelegentliche Alarme fallen dabei nur Centbeträge an Anbieter-Gebühren an.

Wie überwacht man n8n selbst?

Mit einem Heartbeat: Ein Workflow mit Schedule Trigger meldet sich in kurzen Abständen bei einem externen Prüfdienst wie Healthchecks.io oder Uptime Kuma. Bleibt die Meldung aus, alarmiert der externe Dienst. So wird ein Ausfall des n8n-Servers bemerkt, obwohl n8n selbst nichts mehr senden kann.

Ersetzt n8n spezialisierte Alarmierungsdienste wie PagerDuty?

Für kleine Teams mit überschaubarer Systemlandschaft meist ja: Eskalationsstufen, Quittierung und mehrere Kanäle lassen sich in n8n vollständig abbilden. Wer komplexe Bereitschaftspläne mit Rotationen und Dutzenden Beteiligten verwalten muss, ist mit einem spezialisierten Dienst besser bedient.

Funktioniert das auch mit selbst gehostetem n8n?

Ja, alle beschriebenen Bausteine stehen auch in der selbst gehosteten Variante zur Verfügung. Für Betriebe, die Wert auf deutsche Datenhoheit legen, ist das der übliche Weg: Fehlermeldungen verlassen die eigene Umgebung dann nur für den Versand der Benachrichtigung.

Alarmierung ist kein Projekt für Wochen. Ein erster Fehler-Workflow mit zwei Eskalationsstufen steht in wenigen Stunden, der Heartbeat dazu am selben Tag. Beim nächsten nächtlichen Ausfall erfahren Sie es nicht morgens um acht vom Kunden, sondern reagieren nachts um zwei selbst.