Die Fehler, die ich in jedem n8n-/Make-Audit wiederfinde
Jedes Audit ist anders. Andere Branche, andere Tools, andere Datenquellen. Aber wenn ich mir die Ergebnisse im Nachhinein anschaue, tauchen dieselben vier technischen Muster fast immer wieder auf – unabhängig davon, wer den Workflow gebaut hat.
Das ist kein Zufall. Es sind die Stellen, an denen n8n und Make es dir leicht machen, etwas zum Laufen zu bringen, aber schwer, es auch robust zu bauen. Hier sind die vier, in der Reihenfolge, in der ich sie normalerweise finde.
Muster 1: Error-Handling, das den Fehler nicht meldet
Der häufigste Fund zuerst: Ein Workflow-Schritt schlägt fehl, n8n bricht die Ausführung ab – und niemand erfährt davon.
Das passiert, weil das Standardverhalten von n8n und Make genau das ist: fehlschlagen und aufhören. Ohne einen expliziten Error-Workflow oder eine Fehler-Benachrichtigung sieht das erst jemand, wenn er zufällig in die Execution-Historie schaut, oder wenn ein Kunde anruft, weil etwas nicht angekommen ist.
Was ich stattdessen sehen will: Ein definierter Error-Trigger pro kritischem Workflow, der bei Fehlschlag eine Nachricht an einen Slack-Kanal oder eine E-Mail schickt – nicht als nachträgliche Ergänzung, sondern von Anfang an Teil des Workflow-Designs.
Muster 2: Keine Schema-Validierung bei externen Datenquellen
Der zweite Fund ist subtiler und deshalb gefährlicher: Der Workflow läuft weiter, aber die Daten sind falsch.
Das passiert typischerweise, wenn sich das Format einer externen Quelle ändert – ein Feld wird umbenannt, ein API-Response bekommt eine zusätzliche Verschachtelungsebene, ein Provider ändert stillschweigend sein Antwortformat. Der Workflow verarbeitet das trotzdem, meist mit leeren oder falsch zugeordneten Werten, ohne dass irgendwo ein Fehler auftaucht.
Was ich stattdessen sehen will: Eine Validierung direkt nach jedem externen Datenimport, die prüft, ob die erwarteten Felder vorhanden und plausibel sind, bevor die Daten weiterverarbeitet werden. Das kostet einen zusätzlichen Node. Der Aufwand steht in keinem Verhältnis zum Schaden, wenn falsche Daten unbemerkt in ein Kundensystem oder eine Preiskalkulation einfließen.
Muster 3: LLM-Aufrufe ohne Vorfilterung
Der dritte Fund kostet nicht Stabilität, sondern Geld. Jede eingehende Anfrage geht an das teuerste verfügbare Modell, auch die, die ein einfacher Keyword-Check oder eine Regel beantwortet hätte.
Das ist verständlich – ein LLM-Node ist in fünf Minuten eingebaut, eine differenzierte Vorfilterung dauert länger. Aber bei Volumen macht das einen echten Unterschied in der monatlichen Rechnung, ohne dass die Qualität des Ergebnisses steigt.
Was ich stattdessen sehen will: Eine einfache Vorklassifizierung vor dem eigentlichen LLM-Aufruf – Keyword-Matching, Regex, oder ein deutlich günstigeres Modell für die Vorsortierung, das teure Modell nur für die Fälle, die es wirklich braucht.
Muster 4: Kein Übergabepunkt, wenn der Ersteller geht
Der vierte Fund zeigt sich nicht sofort, sondern erst Monate später: Der Workflow läuft, aber niemand außer der Person, die ihn gebaut hat, versteht ihn vollständig. Keine Dokumentation, keine Kommentare in den Nodes, keine Übersicht, welche Systeme an welchen Stellen verbunden sind.
Das wird zum Problem, sobald diese eine Person das Unternehmen verlässt oder mit anderen Projekten beschäftigt ist – dann ist niemand mehr da, der einen Fehler einordnen kann, wenn einer auftritt. Ich habe dazu einen eigenen Artikel über die Freelancer-Perspektive dieses Problems geschrieben.
Was ich stattdessen sehen will: Eine kurze Workflow-Beschreibung pro Automatisierung – Zweck, beteiligte Systeme, bekannte Einschränkungen. Kein aufwendiges Dokument, eine halbe Seite reicht meistens.
Warum diese vier, und nicht andere
Alle vier haben eine Gemeinsamkeit: Sie sind kein Fehler im eigentlichen Sinne, solange nichts passiert. Der Workflow läuft, die Demo funktioniert, alle sind zufrieden. Das Problem zeigt sich erst unter Last, bei einer Änderung an einer externen Quelle, oder wenn die Person geht, die alles im Kopf hatte.
Genau deshalb werden sie beim Bauen übersehen und fallen erst in einem Audit auf – wenn jemand von außen gezielt danach sucht, statt zu prüfen, ob der Workflow „funktioniert“.
Was du selbst prüfen kannst
Bevor du ein Audit brauchst, kannst du diese vier Fragen an deinen eigenen Workflows durchgehen:
1. Was passiert, wenn dieser Schritt fehlschlägt – merkt es jemand? 2. Was passiert, wenn sich das Format der Eingabedaten ändert – fällt das auf? 3. Geht jede Anfrage ans teuerste Modell, oder gibt es eine Vorfilterung? 4. Könnte jemand anderes diesen Workflow in einer Stunde verstehen?
Wenn eine dieser Fragen unangenehm ist, ist das ein guter Ausgangspunkt.
Weitere Ressourcen
Zur Freelancer-Perspektive des Übergabeproblems:
→ Freelancer für Datenprojekte: Warum ich aufgehört habe
Wenn du wissen willst, wo deine eigenen Automatisierungen stehen:
→ Kostenloser KI-Compliance Schnellcheck
Für eine vollständige technische Analyse:
