Fehlerpfade in Automationen: Warum der Demo-Lauf nicht reicht

Ein Demo-Lauf zeigt, dass eine Automation im Idealfall funktioniert: saubere Testdaten, erreichbare Systeme, gültige Zugangsdaten. Im Betrieb trifft jede Automation früher oder später sechs Fälle, die der Demo-Lauf nicht abdeckt: ein doppeltes Ereignis, fehlende Pflichtdaten, einen abgelaufenen Zugang, ein API-Limit, ein nicht erreichbares Zielsystem und ein geändertes Feld. Ohne Fehlerbehandlung geht dabei entweder Arbeit verloren oder es entsteht doppelte. Beides fällt oft erst auf, wenn ein Kunde nachfragt.

Dieser Beitrag beschreibt, wie ein Fehlerpfad für jeden der sechs Fälle aussieht, welche Bausteine dafür nötig sind und wie Sie vor der Abnahme prüfen, ob sie wirklich greifen. Die Beispiele nennen konkrete Funktionen von n8n und Make, die Logik gilt aber für jedes Werkzeug.

Ein Beispiel: vom Formular über das CRM in die Buchhaltung

Ein fiktiver Ablauf zur Veranschaulichung: Ein Großhändler lässt Kunden über ein Webformular ein Angebot anfragen. Die Automation legt den Kontakt im CRM an und erzeugt daraus bei Auftragsbestätigung einen Kundenstammsatz in der Buchhaltung. Drei Systeme, zwei Übergaben. Der Demo-Lauf mit einem Testkontakt läuft glatt durch. Das ist der Zustand, in dem viele Automationen abgenommen werden.

Die folgenden sechs Fälle zeigen, was danach passieren kann. Alle Daten sind erfunden, es handelt sich um kein Kundenprojekt.

Die sechs Fälle, die jede Automation trifft

1. Doppeltes Ereignis

Ohne Fehlerpfad: Das Formular sendet die Anfrage zweimal, weil jemand doppelt geklickt hat oder der Absender die Zustellung wiederholt. Viele Systeme liefern Ereignisse mindestens einmal aus, nicht genau einmal. Im CRM stehen zwei Kontakte, in der Buchhaltung zwei Stammsätze, und der Vertrieb ruft den Kunden doppelt an.

Fehlerpfad: Dublettenschutz über einen Idempotenz-Schlüssel. Aus stabilen Merkmalen des Ereignisses, etwa Formular-ID plus E-Mail-Adresse oder Auftragsnummer, bilden Sie einen Schlüssel. Bevor die Automation etwas anlegt, prüft sie, ob dieser Schlüssel schon vorkommt. Wenn ja, endet der Lauf ohne Schreibzugriff und vermerkt im Protokoll „Dublette, übersprungen“. Wo das Zielsystem es erlaubt, ist „anlegen oder aktualisieren“ besser als „anlegen“. In n8n halten Sie die Schlüssel in einer Data Table (n8n-eigene Tabelle) oder in einer Datenbank, in Make in einem Data Store.

2. Fehlende Pflichtdaten

Ohne Fehlerpfad: Das Formular erlaubt eine leere Firmenangabe, die Buchhaltung verlangt sie. Der Lauf bricht am zweiten Übergang ab. Das CRM ist aktualisiert, die Buchhaltung nicht, und die Systeme laufen auseinander.

Fehlerpfad: Eine Prüfung ganz am Anfang. Fehlt ein Pflichtfeld, legt die Automation nichts an. Der Datensatz wandert stattdessen in eine Nachbearbeitungsliste, und die zuständige Rolle bekommt eine Meldung mit dem Hinweis, welches Feld fehlt. In n8n übernimmt das ein IF-Knoten oder ein Filter, in Make ein Filter am Anfang der Kette mit einer Route für die Ausnahme. Wichtig ist, dass der Datensatz nicht verschwindet: Eine Prüfung, die Daten still verwirft, ersetzt nur ein sichtbares Problem durch ein unsichtbares.

3. Ungültige Zugangsdaten oder abgelaufene Tokens

Ohne Fehlerpfad: Ein Zugriffstoken läuft ab oder ein Passwort wird geändert. Ab diesem Moment scheitert jeder Lauf, aber niemand merkt es. Die Anfragen stauen sich im Formular, bis jemand fragt, warum das CRM so ruhig ist.

Fehlerpfad: Wiederholen hilft hier nicht, denn der Zugang bleibt ungültig. Der Fehlerpfad muss deshalb sofort alarmieren und den Lauf zur späteren Wiederholung aufbewahren. Dazu kommt Vorbeugung: ein Kalendereintrag für bekannte Ablaufdaten, Zugangsdaten im Credential-Speicher des Werkzeugs statt in Notizen, und ein technischer Benutzer statt des privaten Kontos einer Mitarbeiterin.

4. API-Limit erreicht

Ohne Fehlerpfad: Nach einem Import oder Kampagnenstart kommen viele Ereignisse gleichzeitig. Das Zielsystem antwortet mit „zu viele Anfragen“ (HTTP 429), und die Automation wertet das wie einen endgültigen Fehler. Ein Teil der Datensätze kommt an, der Rest nicht, und niemand weiß, welcher.

Fehlerpfad: Wiederholung mit Wartezeit statt in schneller Folge. In n8n stellen Sie am Knoten „Retry On Fail“ mit fester Wartezeit zwischen den Versuchen ein; zunehmende Abstände bauen Sie bei Bedarf mit einem Wait-Knoten und einer Schleife selbst. Bei größeren Mengen ergänzen Sie Stapelverarbeitung mit Pausen. In Make nutzen Sie den Error Handler „Retry“: Er legt den Lauf als unvollständige Ausführung ab und wiederholt ihn in einstellbarem Abstand, wenn „Automatically complete execution“ aktiv ist. Verbindungs- und Limitfehler wiederholt Make bei gespeicherten unvollständigen Ausführungen ohnehin automatisch. Nach der letzten Wiederholung greift der Alarm.

5. Zielsystem nicht erreichbar

Ohne Fehlerpfad: Die Buchhaltung ist wegen Wartung oder einer Störung für einige Zeit nicht erreichbar. Alle Läufe in diesem Zeitraum scheitern. Wer sie später nachholen will, muss herausfinden, welche es waren, und baut dabei leicht Dubletten.

Fehlerpfad: Dieselbe Wiederholung wie beim API-Limit, dazu ein Protokolleintrag je gescheitertem Lauf mit den Eingangsdaten. So lässt sich der Lauf nach der Störung gezielt wiederholen, und der Dublettenschutz aus Fall 1 sorgt dafür, dass bereits Angelegtes nicht erneut entsteht.

6. Geändertes Feld

Ohne Fehlerpfad: Jemand benennt im CRM ein Feld um oder ändert eine Auswahlliste. Die Automation schreibt weiter, aber in ein Feld, das es so nicht mehr gibt, oder mit einem Wert, den das Ziel nicht kennt. Je nach System bricht der Lauf ab, oder schlimmer: Er läuft durch und schreibt Leeres.

Fehlerpfad: Zwei Schichten. Erstens eine Prüfung der erwarteten Struktur am Anfang: Fehlt ein Feld in den Eingangsdaten, stoppt der Lauf mit einer klaren Fehlermeldung (in n8n über den Knoten „Stop And Error“). Zweitens organisatorisch: Wer Felder in angebundenen Systemen ändert, muss wissen, dass Automationen daran hängen. Eine Liste der Abhängigkeiten gehört ins Runbook.

Die Bausteine eines Fehlerpfads

Die sechs Fälle lassen sich mit sechs Bausteinen abdecken. Nicht jede Automation braucht alle gleich ausgeprägt, aber jeder Baustein sollte bewusst vorhanden oder bewusst weggelassen sein.

• Idempotenz-Schlüssel und Dublettenschutz. Jedes Ereignis bekommt einen stabilen Schlüssel, und die Automation prüft ihn vor dem Schreiben. Das ist die Voraussetzung für alles andere, vor allem für sicheres Wiederholen.
• Wiederholung mit Wartezeit. Gedacht für vorübergehende Fehler wie Limits und Ausfälle. Für dauerhafte Fehler wie ungültige Zugänge wiederholen Sie nicht endlos, sondern alarmieren.
• Fehlerworkflow. In n8n legen Sie einen eigenen Workflow mit dem Error Trigger an und tragen ihn in den Einstellungen der übrigen Workflows als Error Workflow ein. Er erhält Name des Workflows, Fehlermeldung und Link zur Ausführung. Beachten Sie, dass dieser Weg bei automatisch gestarteten Läufen greift, nicht beim manuellen Testen im Editor. In Make hängen Sie an ein Modul einen Error Handler. Er kennt unter anderem Resume (mit Ersatzwert weitermachen), Rollback (bereits Geschriebenes zurücknehmen, nur wo das Modul das unterstützt) und Retry (früher Break: Lauf als unvollständig speichern und in einstellbarem Abstand wiederholen). Dazu kommt Skip, das den fehlerhaften Datensatz überspringt und die übrigen weiterverarbeitet. Für Retry muss die Speicherung unvollständiger Läufe im Szenario eingeschaltet sein.
• Protokoll. Je Lauf: Schlüssel, Zeitpunkt, Ergebnis (angelegt, aktualisiert, übersprungen, fehlgeschlagen) und der Grund. Ein Protokoll beantwortet die Frage „Ist Auftrag 4711 angekommen?“ mit einem Blick statt durch Suchen in drei Systemen.
• Alarmierung an einen benannten Menschen. Eine Fehlermeldung an ein Sammelpostfach, das niemand liest, ist kein Alarm. Der Alarm geht an eine Rolle mit Stellvertretung und enthält, was passiert ist, welcher Datensatz betroffen ist und was als Nächstes zu tun ist.
• Runbook. Ein kurzes Dokument je Automation: Was macht sie, welche Systeme hängen dran, welche Alarme gibt es und was tut man bei jedem. Das Runbook ist der Unterschied zwischen „Der Alarm kam“ und „Der Alarm wurde bearbeitet“.

Der Testplan vor der Abnahme

Der Demo-Lauf prüft den Idealfall. Eine Abnahme sollte dagegen alle sechs Fälle absichtlich auslösen. Das geht in einer Testumgebung oder mit Testdatensätzen, ohne die produktiven Systeme zu gefährden:

Fall	Testfall	Erwartetes Ergebnis
Doppeltes Ereignis	Dasselbe Formular zweimal absenden	Ein Kontakt im CRM, ein Stammsatz in der Buchhaltung, im Protokoll „Dublette, übersprungen“
Fehlende Pflichtdaten	Formular ohne Firmenangabe	Nichts angelegt, Datensatz in der Nachbearbeitung, Meldung an die zuständige Rolle
Ungültiger Zugang	Zugang im Testsystem ungültig machen	Sofortiger Alarm, Lauf aufbewahrt, nach Erneuerung wiederholbar
API-Limit	Viele Ereignisse gleichzeitig senden	Verzögerte Verarbeitung statt Verlust, am Ende alles angekommen, nichts doppelt
Zielsystem nicht erreichbar	Testsystem abschalten oder sperren	Wiederholung, danach Alarm, spätere Nachholung ohne Dubletten
Geändertes Feld	Feld im Testsystem umbenennen	Lauf stoppt mit klarer Meldung, kein Schreiben ins Leere

Zusätzlich gehört ein Alarm-Test dazu: Löst der Fehler wirklich eine Nachricht aus, und erreicht sie die benannte Person? Erst wenn alle sechs Fälle und der Alarm wie erwartet reagieren, ist die Automation abnahmefähig.

Was „benannter Betreiber beim Kunden“ bedeutet

Ein Fehlerpfad löst Probleme nur so weit, wie jemand die Alarme sieht und handelt. Deshalb gehört zu jeder Automation ein benannter Betreiber auf Kundenseite. Das ist eine Person mit Stellvertretung, die den Alarm erhält, den Datensatz einordnen kann und im Runbook nachschlägt, was zu tun ist. Sie muss kein Entwickler sein, aber entscheiden können, ob eine Dublette ein Fehler ist, ob ein Auftrag nachgeholt wird und wen sie im Zweifel anruft.

Die Instanz gehört Ihnen, ebenso die Zugangsdaten und die Verantwortung für den Betrieb. Ich richte ein, baue, übergebe und betreue zu Geschäftszeiten. Eine Rufbereitschaft biete ich nicht an. Kritische Abläufe brauchen deshalb zusätzlich eine Rückfallebene, die ohne mich funktioniert, zum Beispiel einen manuellen Weg für Aufträge, solange die Automation steht. Wie das in der Praxis aussieht, beschreibe ich auf der Seite zu Managed Automation.

Ein Fehlerpfad ist kein Zusatz

Fehlerpfade lassen sich nachträglich ergänzen, aber sie sind aufwendiger, wenn die Automation ohne Dublettenschutz und Protokoll gebaut wurde, weil dann der Schlüssel fehlt, auf den alles andere aufbaut. Planen Sie sie deshalb vom ersten Workflow an mit. Das gilt für n8n und Make gleichermaßen. Eine tool-neutrale Variante mit einem Workflow und bis zu drei Systemen finden Sie unter Workflow-Pilot. Wie ich den Einstieg gestalte, steht im Überblick zur n8n-Beratung. Wenn Sie erst klären möchten, welche Abläufe überhaupt einen Fehlerpfad brauchen, ist das Integrations-Audit der Einstieg; für Make-Szenarien gilt dasselbe, siehe Make-Beratung.

Häufige Fragen

Wie viele Wiederholungen sind sinnvoll?

Für vorübergehende Fehler wie Limits und kurze Ausfälle reichen wenige Versuche mit Wartezeit. Wiederholen Sie nicht endlos: Wer ein dauerhaft ungültiges Passwort hundertfach versucht, sperrt im ungünstigen Fall das Konto. Nach der letzten Wiederholung muss der Alarm greifen, und der Lauf bleibt zur manuellen Wiederholung erhalten.

Was ist der Unterschied zwischen Error Workflow und Error Handler?

Beide fangen Fehler ab, aber an verschiedenen Stellen. Der Error Workflow in n8n ist ein eigener Workflow, der startet, wenn irgendein Lauf eines verknüpften Workflows fehlschlägt. Die Error Handler in Make hängen dagegen an einzelnen Modulen und legen fest, was bei einem Fehler genau dort geschieht, etwa Resume, Rollback oder Retry. In n8n können Sie zusätzlich je Knoten festlegen, ob der Lauf bei einem Fehler weitergeht.

Reicht eine E-Mail bei Fehlern als Alarmierung?

Technisch ja, praktisch nur, wenn sie bei einer benannten Person landet, die sie liest, und genug Information enthält, um zu handeln. Ein Sammelpostfach oder eine Mail ohne Hinweis auf Datensatz und nächsten Schritt erzeugt Meldungen, die mit der Zeit ignoriert werden. Chat-Nachrichten oder Tickets eignen sich ebenso, wenn die Zuständigkeit klar ist.

Ihr nächster Schritt

Sie haben Automationen im Einsatz oder planen den ersten Workflow und möchten wissen, ob die sechs Fälle abgedeckt sind? Im kostenlosen Erstgespräch gehe ich Ihren Ablauf mit Ihnen durch und zeige, wo ein Fehlerpfad fehlt. Sie können es hier anfragen.

Weiterlesen

Vergleichen Sie die Kosten von Zapier, Make und n8n, prüfen Sie n8n Self-Hosting oder Cloud oder lesen Sie, wie der Umstieg von Zapier in fünf Schritten gelingt.

n8n, Make und Zapier sind Marken ihrer jeweiligen Inhaber. Die Beratung ist unabhängig und ohne Partnerschaft oder Zertifizierung bei einem dieser Hersteller.