Ein Automation-Lauf scheitert, und der erste Reflex ist: noch einmal versuchen. Dabei wiederholt manche Wiederholung nur denselben Fehler.

Der Schritt bricht mit einer Fehlermeldung ab, zum Beispiel „ungültiges Feld“. Nach einem Klick auf Wiederholen erscheint exakt dieselbe Meldung. Nach zehn Versuchen steht man am gleichen Punkt.

Ein Retry ist das erneute Ausführen eines einzelnen fehlgeschlagenen Schritts, ohne den ganzen Ablauf neu zu starten. Sinnvoll ist er nur bei vorübergehenden Fehlern, also Störungen, die von selbst verschwinden. Bei ungültigen Daten liefert derselbe Aufruf dieselbe Ablehnung. Erst ein Blick auf die Ursache entscheidet, ob ein Retry hilft.

Eine Automation liest zweihundert Kontakte aus einer Adress-API, also einer programmierbaren Schnittstelle. Das Limit liegt bei hundert Anfragen pro Minute; ab der einhundertundersten kommt 429 Too Many Requests zurück. Der mitgesendete Retry-After-Header nennt die Wartezeit, danach gelingt dieselbe Anfrage. Anders bei 400 oder 422: Diese Codes bedeuten ungültige Daten, und jede Wiederholung scheitert sofort wieder.

So prüft man es: Zuerst die Fehlerursache lesen, etwa den Statuscode der Meldung. Transportstörung, 429 oder 5xx sprechen für Wiederholung, „fehlender Wert“ spricht dagegen.

Die Grundregel lautet: mit begrenzter Anzahl Versuchen und mit Verzögerung wiederholen, nicht sofort und nicht endlos. Beim exponentiellen Backoff wächst die Wartezeit mit jedem Versuch bis zu einer Obergrenze. In n8n stellt man das je Node über Retry On Fail ein; Nachrichten, die trotzdem scheitern, gehören in eine Dead-Letter-Ablage zur manuellen Prüfung.

Ein Retry heilt keine ungültigen Daten, sondern nur vorübergehende Störungen. Wer die Ursache nicht prüft, wiederholt nur den Fehler.

📌 Retry · Vorübergehender Fehler · Exponentieller Backoff

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #n8n #api #workflow