3 Gründe, warum deine n8n-Automatisierung ständig bricht
Ich sehe in fast jedem Audit dasselbe Bild. Ein n8n- oder Make-Workflow, der vor einem Jahr in drei Tagen zusammengebaut wurde, läuft seitdem im Hintergrund und schickt einmal im Monat still eine Fehlermeldung, die keiner mehr liest. Bis ein Kunde anruft, weil seine Bestellbestätigung nie angekommen ist.
Wenn ich dann frage, wer das gebaut hat, kommt fast immer dieselbe Antwort: eine Agentur, ein Freelancer, oder „das haben wir schnell selbst gemacht, weil es ja nur ein einfacher Workflow war.“
Genau da liegt das Problem. n8n und Make machen es so einfach, etwas zum Laufen zu bringen, dass niemand merkt, wie viel dabei fehlt, um es auch am Laufen zu halten. Drei Muster tauchen dabei immer wieder auf.
Grund 1: Kein Error-Handling, das den Fehler auch meldet
Der Standardfall in n8n: Ein HTTP-Request-Node ruft eine API auf. Die API antwortet mit einem Fehlercode. Der Workflow bricht ab. Das war’s.
Niemand bekommt eine Benachrichtigung. Kein Slack-Ping, keine E-Mail, kein Eintrag irgendwo. Der Workflow-Status in n8n zeigt zwar „Failed“ an, aber das sieht sich niemand aktiv an, weil dafür ja ein Mensch regelmäßig ins Interface schauen müsste.
Das Tückische daran: Solange die API meistens funktioniert, merkt keiner etwas. Der Fehler zeigt sich erst, wenn genug Zeit vergangen ist, dass irgendwer fragt, wo die Daten geblieben sind. Bei einem Bestellworkflow ist das der Kunde. Bei einer internen Reporting-Pipeline ist das der Monatsabschluss, der plötzlich nicht mehr stimmt.
Was in jeden produktiven Workflow gehört:
- Ein Error-Trigger-Workflow, der bei jedem Fehlschlag automatisch eine Nachricht an einen konkreten Kanal schickt, nicht nur ins n8n-Log
- Retry-Logik mit Backoff für Nodes, die externe APIs aufrufen, weil viele Fehler nur temporäre Aussetzer sind
- Ein Zähler oder Dashboard, das zeigt, wie oft ein Workflow in den letzten 30 Tagen fehlgeschlagen ist
Das ist keine große Sache, technisch gesehen. Es sind vielleicht zwei zusätzliche Nodes und ein Webhook. Aber es fehlt fast überall, weil Error-Handling beim ersten Bauen nie das dringende Problem ist. Das Ding soll ja erstmal laufen.
Grund 2: Keine Schema-Validierung, wenn sich die Quelle ändert
Der zweite Klassiker: Ein Workflow liest Daten aus einer externen Quelle, einem Webshop-Export, einer API, einer Webseite. Irgendwann ändert sich dort ein Feldname, ein Datumsformat, eine Struktur. Kein Ankündigung, keine Versionsnummer, einfach eine stille Änderung auf der anderen Seite.
Dein Workflow läuft trotzdem weiter. Nur die Daten stimmen nicht mehr. Ein Datumsfeld wird als Text interpretiert. Ein neues Pflichtfeld fehlt, und die nachgelagerte Verarbeitung füllt es stillschweigend mit einem leeren String auf.
Das Perfide daran ist genau das: Es gibt keinen Absturz, den man debuggen könnte. Es gibt einfach falsche Daten, die so aussehen, als wären sie richtig. Bei einer Preisbeobachtung heißt das: falsche Preise im System, wochenlang, bis jemand zufällig draufschaut.
Die Lösung dafür ist unspektakulär, aber wirksam: eine Schema-Prüfung direkt nach dem Datenempfang, bevor irgendetwas weiterverarbeitet wird. Erwartete Felder, erwartete Typen, erwarteter Wertebereich. Wenn etwas nicht passt, bricht der Workflow kontrolliert ab und meldet genau, was nicht gepasst hat, statt einfach mit falschen Daten weiterzumachen.
Grund 3: LLM-Aufrufe ohne Vorfilterung
Seit n8n und Make LLM-Nodes eingebaut haben, sehe ich ein drittes Muster immer öfter: Jede einzelne Zeile, jede Anfrage, jedes Ticket geht ungefiltert an ein Sprachmodell, selbst für Aufgaben, die eigentlich keine KI brauchen.
Ein Beispiel aus einem echten Audit: Ein Support-Workflow hat jedes eingehende Ticket per LLM klassifizieren lassen, ob es sich um eine Rechnungsfrage, eine technische Frage oder eine Stornierung handelt. Für Tickets, die das Wort „Rechnung“ oder „Storno“ bereits im Betreff hatten, war das eine teure Umwegantwort auf eine Frage, die ein einfacher Keyword-Check in einer Zeile Code beantwortet hätte.
Zwei Konsequenzen davon sieht man in fast jedem Audit:
| Symptom | Ursache | Fix |
|---|---|---|
| API-Kosten steigen monatlich, ohne dass das Volumen wächst | Jeder Case geht ans teuerste verfügbare Modell | Model-Tiering: günstigeres Modell für Standardfälle, teures Modell nur für Edge-Cases |
| Antwortzeiten schwanken stark | Kein Caching für wiederkehrende, fast identische Anfragen | Lokales Caching für semantisch ähnliche Anfragen |
| Klassifizierung ist unnötig langsam | Einfache Regeln laufen erst nach dem LLM-Aufruf, nicht davor | Deterministische Vorfilterung mit Regex oder einfachen Keywords, bevor überhaupt ein API-Call passiert |
Das ist keine Kritik an LLMs in Automatisierungen. Es ist eine Kritik daran, sie für Aufgaben einzusetzen, die auch ohne sie funktionieren, und dabei jeden Monat unnötig Geld zu verbrennen.
Was diese drei Punkte gemeinsam haben
Keiner davon ist kompliziert. Kein einziger erfordert eine neue Plattform oder ein größeres Redesign. Genau das macht es so ärgerlich: Es sind Dinge, die in jedes seriöse Setup von Anfang an reingehört hätten, und die trotzdem fast nie drin sind, wenn ein Workflow schnell gebaut wurde.
Ein Nebeneffekt, den ich in Audits fast immer zusätzlich finde, wenn ich mir diese Workflows genauer ansehe: Kundendaten landen dabei unverschlüsselt bei US-APIs, weil auch das beim schnellen Bauen niemand bedacht hat. Das ist ein eigenes, akutes DSGVO-Thema, unabhängig von der Stabilität des Workflows selbst.
Wenn du wissen willst, wo genau deine n8n- oder Make-Infrastruktur an diesen drei Punkten steht: Ich mache dafür eine technische Tiefenprüfung, die genau das systematisch durchgeht, statt nur oberflächlich draufzuschauen.
