n8n im Produktivbetrieb: Was bricht, wenn ein Workflow geschäftskritisch wird

Einen funktionierenden n8n-Workflow zu bauen ist leicht. Genau darum geht es bei n8n, und es ist ein wirklich gutes Werkzeug.

Was nicht leicht ist — und wovor niemand warnt — ist der Übergang von „das funktioniert" zu „ein Unternehmen verlässt sich darauf, dass das sonntags um 03:00 Uhr korrekt läuft, während niemand hinschaut". Dieser Übergang hat bestimmte Fehlermuster, und es sind jedes Mal dieselben.

Das sind die, auf die ich immer wieder stoße, ungefähr in der Reihenfolge, in der sie zuschlagen.

1. Wiederholungsversuche, die Nebenwirkungen verdoppeln

Das ist das erste und das teuerste Problem.

Ein Node fällt bei einem kurzen Netzwerkaussetzer aus. n8n versucht es erneut. Der zweite Versuch gelingt. Nur hatte der erste Versuch die Rechnung bereits erstellt, bevor er beim Warten auf die Antwort in den Timeout lief — es gibt also zwei Rechnungen, und einen Monat lang merkt es niemand.

Alles, was nach außen schreibt, muss idempotent sein: Zweimal ausgeführt muss dasselbe Ergebnis herauskommen wie bei einmaliger Ausführung. In der Praxis:

Schicke bei jedem Erstellungs-Request einen deterministischen Idempotency Key mit, falls die API das unterstützt. Viele tun es; fast niemand nutzt es.
Wenn die API das nicht kann: erst prüfen, dann anlegen — den Datensatz zuerst über einen natürlichen Schlüssel abfragen.
Ordne die Nodes so, dass der Schreibvorgang das Letzte ist, was passiert. Ein Workflow, der schreibt und danach noch fünf Schritte macht, hat fünf weitere Gelegenheiten, nach dem unumkehrbaren Teil zu scheitern.

Meine Regel: Bevor du Retries an einem Node aktivierst, frage dich, was passiert, wenn er zweimal läuft. Wenn du das nicht beantworten kannst, aktiviere sie nicht.

2. Kein Error-Workflow, also bleiben Fehler stumm

Der Standardzustand einer kaputten Automatisierung ist kein Alarm. Es ist Stille — und Stille sieht genauso aus wie Erfolg.

Richte in jedem Produktiv-Workflow ab dem ersten Tag einen Error-Workflow ein (Settings → Error Workflow). Er sollte zwei Dinge tun: einen Menschen dort benachrichtigen, wo dieser Mensch auch wirklich hinschaut, und genug Kontext zur Diagnose mitliefern — welcher Workflow, welche Execution-ID, welcher Node und welche Eingangsdaten den Fehler ausgelöst haben.

Die subtilere Variante dieses Problems: Workflows, die scheitern, indem sie nichts tun. Ein Trigger, der aufhört zu feuern, erzeugt überhaupt keinen Fehler, weil nichts gelaufen ist. Das ist der Ausfall, den drei Wochen lang niemand bemerkt. Die einzige verlässliche Antwort ist ein Totmannschalter: eine separate geplante Prüfung, die Alarm schlägt, wenn der erwartete Lauf nicht stattgefunden hat.

3. Der eine riesige Workflow

Jede gereifte n8n-Installation, die ich gesehen habe, hat einen Workflow mit sechzig Nodes, den niemand anfassen will. Angefangen hat er meist mit zwölf.

Der Preis ist nicht ästhetisch. Er besteht darin, dass du einen fehlgeschlagenen Schritt in der Mitte nicht wiederholen kannst, ohne alles davor erneut auszuführen — und bei allem mit Nebenwirkungen heißt das, dass du ihn gar nicht wiederholen kannst. Fehler erfordern dann Handarbeit statt eines Retrys.

Teile an den Stellen, an denen du wieder aufsetzen möchtest. Ein übergeordneter Workflow, der Sub-Workflows per Execute Workflow aufruft, kostet etwas Übersicht im Editor und erkauft dir die Möglichkeit, eine Stufe zu reparieren, ohne die anderen anzufassen.

4. Zugangsdaten, die am Feiertag ablaufen

OAuth-Tokens laufen ab. API-Schlüssel werden von einer IT-Abteilung rotiert, die nichts von deinem Workflow weiß. Zertifikate verfallen. All das erzeugt Authentifizierungsfehler, die wie ein plötzlicher, rätselhafter Defekt aussehen.

Zwei Gewohnheiten helfen. Führe eine Übersicht darüber, welche Workflows welche Zugangsdaten nutzen — eine Tabelle irgendwo, kein Erfahrungswissen im Kopf. Und lass die Meldung des Error-Workflows Authentifizierungsfehler von allem anderen unterscheiden, denn ein Auth-Fehler hat eine bekannte, feste Ursache und sollte keine vierzig Minuten Fehlersuche kosten.

5. Datenmenge und Arbeitsspeicher

n8n reicht Daten zwischen Nodes im Arbeitsspeicher weiter. Das ist unproblematisch, bis jemand eine 200-MB-Datei hochlädt oder eine Abfrage, die sonst 50 Zeilen liefert, plötzlich 500.000 zurückgibt, weil ein Filter klammheimlich nicht mehr griff.

Sichere die Eingabe ab. Baue früh im Workflow eine explizite Prüfung der Batch-Größe ein und brich laut ab, wenn sie das übersteigt, wofür du gebaut hast. „Zu viele Elemente, Abbruch" ist ein deutlich besseres Ergebnis als ein Out-of-Memory-Absturz mitten in der Verarbeitung, bei dem ein Teil der Datensätze geschrieben ist und ein Teil nicht.

Bei wirklich großen Jobs verarbeite in Batches mit einer Schleife und reiche Referenzen weiter — Datei-IDs, URLs — statt den Dateiinhalt zwischen jedem Node zu transportieren.

6. Keine Versionshistorie, die etwas taugt

Der Editor ist eine laufende Produktivumgebung. Du bearbeitest, du speicherst, es ist live. Kein Pull Request, kein Diff, kein Review.

Mein heutiges Minimum: Produktiv-Workflows als JSON exportieren und regelmäßig in git committen. Das ist keine saubere Versionsverwaltung — die Diffs sind hässliches, kaum lesbares JSON — aber du kannst damit beantworten, „was sich am Dienstag geändert hat", und eine funktionierende Version wiederherstellen.

Besser, wenn der Workflow wichtig ist: getrennte Entwicklungs- und Produktivinstanzen, und der Weg nach vorne führt über den Import. Langsamer — und genau einmal jeden Aufwand wert.

7. Niemand weiß, was „funktioniert" heißt

Eine Automatisierung ist nicht korrekt, weil sie keinen Fehler geworfen hat. Sie ist korrekt, weil sie das richtige Ergebnis erzeugt hat.

Dieser Unterschied zählt am meisten bei allem, wo ein LLM beteiligt ist: Der Workflow läuft dort fröhlich erfolgreich durch und produziert dabei Unsinn. Aber er gilt auch für gewöhnliche Automatisierungen: Eine Datensynchronisation, die sauber durchläuft und das falsche Feld synchronisiert, ist ein grüner Haken und ein stilles Problem.

Was hilft: schon beim Bauen eine prüfbare Aussage über das Ergebnis festlegen — eine Anzahl, die übereinstimmen muss, eine Summe, die aufgehen muss, ein Feld, das nie leer sein darf — und den Workflow das prüfen und abbrechen lassen, wenn es nicht zutrifft. Das ist unspektakulär und fängt genau die Fehlerklasse ab, die Monitoring nie erwischt.

8. Self-Hosting-Entscheidungen, einmal getroffen, später bereut

Wenn du selbst hostest — was ich tue — lohnt es sich, drei Dinge bewusst zu entscheiden statt per Voreinstellung:

Aufbewahrung der Ausführungsdaten. n8n speichert die Ausführungshistorie samt der Daten, die durchgelaufen sind. Bei einem Workflow mit personenbezogenen Daten ist das ein stilles DSGVO-Risiko in deiner Datenbank. Setze eine Aufbewahrungsfrist; lass sie nicht auf „für immer" stehen.
Queue-Modus. Der reguläre Modus ist einfacher und reicht, bis Nebenläufigkeit wichtig wird. Später zu wechseln ist eine Migration; früh zu entscheiden ist eine Konfiguration.
Backups, die die Datenbank einschließen. Dort liegen die Workflows, dazu Zugangsdaten und Historie. Den Container zu sichern, aber nicht die Datenbank, heißt nichts zu sichern, was zählt.

Die Kurzfassung

Wenn du eines mitnimmst: Bevor ein Workflow live geht, schreibe auf, was passiert, wenn jeder einzelne Node ausfällt — und was passiert, wenn er zweimal läuft. Zehn Minuten mit einem Blatt Papier. Fast jeder Produktionsvorfall, den ich mit n8n hatte, wäre bei dieser Übung aufgefallen — und die, die es nicht gewesen wären, waren abgelaufene Zugangsdaten, weshalb es Punkt vier gibt.

n8n ist nicht fragil. Es ist ein wirklich gutes Werkzeug, das das Bauen so leicht macht, dass Leute den Teil überspringen, in dem man über das Scheitern nachdenkt. Nicht das Werkzeug ist das Problem, sondern die fehlenden zehn Minuten.