Jede Automatisierung scheitert irgendwann: Eine Schnittstelle ist kurz nicht erreichbar, ein Lieferant ändert das Format seiner Datei, ein Limit ist erreicht. Das ist normal und kein Grund zur Sorge. Gefährlich wird es erst, wenn niemand merkt, dass der Prozess steht. Dieser Artikel zeigt Geschäftsführern und Prozessverantwortlichen, wie man automatisierte Abläufe so baut, dass Fehler abgefangen, gemeldet und nachvollziehbar werden – am Beispiel von n8n, aber mit Prinzipien, die für jedes Werkzeug gelten.
Das eigentliche Risiko ist nicht der Fehler, sondern das Schweigen
In Gesprächen mit Betrieben erlebe ich zwei Sorten von Automatisierungsfehlern. Die erste fällt sofort auf: Der Workflow bricht ab, die erwartete E-Mail kommt nicht, jemand beschwert sich. Unangenehm, aber harmlos – der Fehler meldet sich selbst. Die zweite Sorte ist die teure: Der Prozess läuft scheinbar weiter, verarbeitet aber seit drei Wochen keine neuen Aufträge mehr, weil eine Schnittstelle stillschweigend leere Ergebnisse zurückgibt. Aufgefallen ist es erst, als ein Kunde nachfragte.
Genau das untergräbt das Vertrauen in Automatisierung schneller als jeder offensichtliche Absturz. Es ist auch ein Grund, warum ambitionierte Projekte scheitern: Gartner prognostiziert (Juni 2025), dass über 40 % der Agentic-AI-Projekte bis Ende 2027 abgebrochen werden – unter anderem wegen unzureichender Risikokontrollen. Wer automatisiert, muss deshalb von Anfang an die Frage beantworten: Woran merke ich, dass etwas nicht funktioniert?
Eine Automatisierung, die unbemerkt ausfällt, ist gefährlicher als gar keine Automatisierung: Solange niemand merkt, dass der Prozess steht, verlassen sich alle weiter darauf. Zuverlässigkeit entsteht nicht dadurch, dass ein Workflow nie scheitert – sondern dadurch, dass jeder Fehler sofort sichtbar wird und jemand weiß, was dann zu tun ist.
Drei Ebenen, auf denen man Fehler abfängt
Fehlerbehandlung ist kein einzelner Schalter, sondern entsteht auf drei Ebenen: am einzelnen Schritt, am gesamten Workflow und bei den fachlichen Prüfungen, die Sie selbst einbauen. Wer alle drei kennt, baut robustere Abläufe – und versteht besser, was eine seriöse Umsetzung von einem schnell zusammengeklickten Prototyp unterscheidet.
1. Der einzelne Schritt: Wiederholen oder bewusst weitermachen
Viele Fehler sind vorübergehend (transient): Eine Anfrage läuft in einen Timeout, ein API-Limit ist kurz erreicht, ein Server antwortet eine Sekunde zu spät. Für solche Fälle hat jeder Node in n8n im Reiter Settings die Option Retry On Fail – schlägt die Ausführung fehl, wiederholt der Schritt sie automatisch, bis er erfolgreich ist. Das fängt einen Großteil der Netzwerk- und Lastprobleme ab, ohne dass ein Mensch eingreift.
Für den Fall, dass ein Schritt trotzdem scheitert, steuert die Einstellung On Error, wie es weitergeht:
- Stop Workflow: Der gesamte Workflow stoppt. Sinnvoll, wenn die folgenden Schritte ohne dieses Ergebnis keinen Sinn ergeben.
- Continue: Der Workflow läuft mit den letzten gültigen Daten weiter. Passend für unkritische Nebenschritte.
- Continue (using error output): Der Workflow läuft weiter und gibt die Fehlerinformation an einen separaten Ausgang, den Sie gezielt behandeln können – etwa, um das fehlerhafte Element in eine Prüfliste zu schreiben.
Die Faustregel: Wiederholen Sie, was sich von selbst erledigen kann, und entscheiden Sie bewusst, ob ein einzelner Fehler den ganzen Prozess stoppen soll oder nicht.
2. Der ganze Workflow: ein eigener Fehler-Workflow
Die wichtigste Ebene ist die Benachrichtigung. n8n erlaubt für jeden Workflow unter Workflow Settings → Error workflow einen separaten Fehler-Workflow, der automatisch startet, sobald eine Ausführung scheitert. Dieser Fehler-Workflow beginnt mit dem Error Trigger-Node und kann von dort aus alles tun: eine E-Mail an die richtige Person schicken, eine Nachricht in einen Slack- oder Teams-Kanal posten, einen Eintrag in einem Ticketsystem anlegen.
Der Error Trigger bekommt dabei nützliche Daten mitgeliefert: welcher Workflow betroffen ist (workflow.name), an welchem Schritt es hakte (execution.lastNodeExecuted), die Fehlermeldung (execution.error.message) und einen direkten Link zur fehlgeschlagenen Ausführung (execution.url). Damit steht in der Alarm-E-Mail nicht nur „etwas ist schiefgelaufen“, sondern „Workflow Rechnungseingang ist beim Schritt PDF auslesen gescheitert – hier klicken“.
Drei Dinge sind in der Praxis wichtig:
- Ein Fehler-Workflow reicht für viele. Sie bauen ihn einmal und tragen ihn in den Einstellungen aller produktiven Workflows ein.
- Im Testlauf feuert er nicht. Laut n8n-Dokumentation lässt sich ein Fehler-Workflow nicht über die manuelle Ausführung testen – der Error Trigger startet nur, wenn ein aktiver, automatisch laufender Workflow scheitert. Man muss einen echten Fehler provozieren, um die Alarmkette zu prüfen.
- Den Alarm gezielt richten. Eine Fehlermeldung, die in einem niemand liest, ist so gut wie keine. Legen Sie fest, wer benachrichtigt wird und was die Person dann tun soll.
Die offizielle Anleitung dazu steht in der n8n-Dokumentation zur Fehlerbehandlung. Wer überlegt, ob ein solches Setup im eigenen Betrieb tragfähig ist, findet auf meiner Seite zur n8n-Beratung den größeren Rahmen.
3. Fachliche Fehler bewusst erzwingen
Nicht jeder Fehler ist technisch. Oft sind die Daten technisch in Ordnung, fachlich aber falsch: ein Rechnungsbetrag von null Euro, ein Lieferdatum in der Vergangenheit, eine fehlende Kundennummer. Solche Fälle würde ein Workflow ohne Prüfung klaglos weiterverarbeiten. Hier hilft der Stop And Error-Node: Er wirft auf Wunsch einen Fehler – als einfache Error Message oder als strukturiertes Error Object – und löst damit dieselbe Alarmkette aus wie ein technischer Absturz.
So machen Sie aus stillen Datenproblemen sichtbare Fehler. Eine Plausibilitätsprüfung, die im Zweifel bewusst abbricht, ist fast immer besser als ein Prozess, der falsche Daten zuverlässig durchwinkt.
Transiente oder fachliche Fehler? Die Reaktion unterscheidet sich
Welche Technik wann passt, hängt von der Fehlerart ab:
| Fehlerart | Sinnvolle Reaktion |
|---|---|
| Transient – Timeout, API-Limit, kurzer Ausfall | Retry On Fail: automatisch wiederholen |
| Fachlich – leerer Betrag, fehlendes Pflichtfeld | Stop And Error: in eine Prüfliste für einen Menschen |
| Kritisch – Folgeschritte sind ohne das Ergebnis sinnlos | On Error → Stop Workflow + Alarm |
| Unkritisch – ein optionaler Nebenschritt scheitert | On Error → Continue, später nacharbeiten |
Überwachen heißt mehr als abfangen
Fehler abzufangen ist die halbe Miete – die andere ist, den laufenden Betrieb sehen zu können. n8n protokolliert jeden Lauf in den Executions-Listen: pro Workflow und übergreifend über alle. Dort sehen Sie Status, Dauer und an welchem Schritt eine Ausführung stehen blieb, und können die Daten einer früheren Ausführung zum Debuggen in den Workflow zurückladen. Wichtig zu wissen: Nur aktive, produktiv laufende Workflows erzeugen automatische Ausführungen – ein Workflow, den niemand auf Active gesetzt hat, läuft schlicht nie.
Für ernsthafte Überwachung über das Mitlesen hinaus bietet n8n in den höheren Tarifen Log-Streaming und OpenTelemetry-Tracing, mit denen sich Ausführungen an externe Monitoring-Systeme anbinden lassen. Für die meisten mittelständischen Setups reicht zu Beginn aber ein einfacher Grundsatz: ein regelmäßiger, automatischer „Lebenszeichen“-Check. Ein Workflow, der einmal täglich meldet „Ich laufe, X Vorgänge verarbeitet“, fällt durch sein Schweigen auf, lange bevor ein Kunde anruft.
Was ich Betrieben rate
Aus der Beratungspraxis drei Faustregeln, die unabhängig vom Werkzeug gelten:
- Doppelverarbeitung verhindern. Wenn ein Workflow nach einem Fehler erneut anläuft, darf er denselben Auftrag nicht zweimal verbuchen. Deduplizierung über ein eindeutiges Merkmal (Rechnungsnummer, Vorgangs-ID) gehört zu jedem ernsthaften Setup.
- Ausnahmen an Menschen übergeben, nicht verstecken. Was die Automatisierung nicht sicher entscheiden kann, landet in einer Prüfliste – nicht im digitalen Nirwana. Bei Vorgängen mit rechtlicher oder finanzieller Wirkung ist diese menschliche Kontrolle ohnehin geboten; warum, steht in meiner DSGVO-Checkliste für Automatisierungsprojekte.
- Nur automatisieren, was Sie überwachen können. Ein Prozess, dessen Fehler Sie nicht bemerken würden, ist noch nicht reif für die Automatisierung. Das ist auch eines der Kriterien, welche Prozesse sich zuerst lohnen.
Fehlerbehandlung und Monitoring sind kein Luxus, den man später nachrüstet, sondern der Teil, der eine Automatisierung überhaupt erst belastbar macht. Sie sind selten spektakulär – aber sie entscheiden, ob aus einem Pilotprojekt dauerhafte Entlastung wird oder eine Quelle stiller Fehler.
Wenn Sie wissen wollen, ob Ihre bestehenden oder geplanten Workflows robust genug aufgesetzt sind, schauen wir uns das im kostenlosen Prozess-Check gemeinsam an – ehrlich und ohne Verkaufsdruck.