Wenn Automationen scheitern

Die erste Automation, die ich gebaut habe, lief drei Wochen sauber durch und ich war stolz wie Bolle. Dann war an einem Dienstag die API auf der anderen Seite kurz weg, der Workflow brach mittendrin ab, und ein Kunde bekam zwei Bestätigungsmails statt einer. Niemand hatte mir gesagt, dass etwas schiefgelaufen war. Ich habe es erst gemerkt, als der Kunde sich beschwerte.

Das ist der Moment, in dem die meisten merken: Eine Automation zu bauen ist die eine Hälfte. Sie so zu bauen, dass sie auch dann nichts kaputt macht, wenn etwas schiefgeht, ist die andere. Und genau darum geht es hier.

In den vorherigen Lessons hast du gelernt, wie Zapier und n8n funktionieren und was ein Webhook ist. Jetzt schauen wir uns an, was passiert, wenn dieser Webhook eben nicht antwortet. Denn das wird er irgendwann nicht.

Warum Automationen überhaupt scheitern

Eine Automation ist eine Kette. Trigger, dann Schritt eins, dann Schritt zwei, und so weiter. Jeder Schritt redet meistens mit irgendeinem fremden System, einer API, einer Datenbank, einem Mailserver. Und fremde Systeme sind genau das: fremd. Du hast keine Kontrolle darüber.

Die häufigsten Gründe, warum ein Schritt kippt, sind banal. Die andere Seite ist gerade überlastet und antwortet mit einem Fehler. Die Verbindung dauert zu lange und läuft in einen Timeout. Ein Datensatz hat ein Feld, das du nicht erwartet hast, leer oder im falschen Format. Oder ein Limit ist erreicht, zu viele Anfragen in zu kurzer Zeit.

Das Tückische daran: Diese Fehler sind meistens vorübergehend. Eine Sekunde später hätte der gleiche Aufruf funktioniert. Genau deshalb ist die erste Verteidigungslinie kein kompliziertes Konstrukt, sondern einfach nochmal probieren.

Retry, einfach nochmal versuchen

Beide großen Tools haben das eingebaut, und du solltest es fast immer anschalten.

In n8n heißt die Einstellung Retry On Fail und sitzt direkt an jedem einzelnen Node, in den Node-Settings. Du gibst zwei Werte an: Max Tries, also wie oft maximal probiert wird, und Wait Between Tries (ms), also wie lange dazwischen gewartet wird. Ein guter Startwert für die meisten Fälle ist Max Tries 3 und Wait Between Tries 1000, also drei Versuche mit einer Sekunde Pause. Wichtig zu wissen: Die UI deckelt diese Werte. Max Tries geht maximal bis 5, die Wartezeit maximal bis 5000 Millisekunden. Wenn du längere Pausen oder mehr Versuche brauchst, musst du dir mit einer eigenen Schleifen-Logik behelfen, das ist dann aber kein Anfängerthema mehr.

In Zapier funktioniert das anders herum. Statt vorab Retries zu konfigurieren, arbeitest du mit Replay. Ein fehlgeschlagener Zap-Lauf landet in der Zap-History mit Status errored, und du kannst ihn von dort aus erneut abspielen. Auf dem kostenlosen Plan geht das manuell und nur für Läufe mit Fehler-Status. Wer das automatisch haben will, braucht Autoreplay, eine Einstellung die fehlgeschlagene Läufe von selbst nochmal abspielt. Die gibt es allerdings erst ab dem Professional Plan aufwärts. Ein Detail, über das viele stolpern: Wenn du den Zap nach dem Fehler stark veränderst, lassen sich die alten fehlgeschlagenen Läufe nicht mehr sauber wiederholen.

Retry löst erstaunlich viele Probleme. Aber nicht alle. Und hier wird es interessant.

Das Problem mit dem doppelten Ausführen

Stell dir vor, dein Workflow macht zwei Dinge. Erst eine Bestellung in der Datenbank anlegen, dann eine Bestätigungsmail schicken. Die Datenbank klappt, die Mail klappt, aber danach kippt der Workflow aus einem dummen Grund. Retry startet den ganzen Lauf neu. Ergebnis: zweite Bestellung, zweite Mail. Genau mein Dienstags-Problem von oben.

Der Fachbegriff dafür ist Idempotenz. Eine Operation ist idempotent, wenn es egal ist, ob sie einmal oder fünfmal ausgeführt wird, das Ergebnis bleibt gleich. Ein Lichtschalter auf An zu stellen ist idempotent, fünfmal An drücken ändert nichts. Eine neue Bestellung anlegen ist es nicht, jeder Durchlauf erzeugt eine weitere.

Praktisch löst du das mit einem eindeutigen Schlüssel. Jede Bestellung bekommt eine ID, zum Beispiel die Bestellnummer. Bevor dein Workflow eine neue Bestellung anlegt, prüft er: Gibt es zu dieser ID schon einen Eintrag? Wenn ja, überspringen. So wird aus dem gefährlichen "nochmal anlegen" ein harmloses "ist schon da, weiter".

Du musst das nicht überall machen. Aber überall dort, wo dein Workflow etwas Neues erzeugt oder verschickt, das ein Mensch sehen oder bezahlen wird, lohnt sich der Gedanke. Lieber einmal zu viel prüfen als einem Kunden zwei Rechnungen schicken.

Wohin mit den Fällen, die einfach nicht durchgehen

Manchmal hilft kein Retry. Der Datensatz ist kaputt, ein Pflichtfeld fehlt, die Logik passt nicht. Wenn du so einen Fall einfach durchrutschen lässt, verschwindet er still und du erfährst nie davon.

Die Idee, die du dir hier merken solltest, heißt Dead Letter, sinngemäß der Briefkasten für unzustellbare Post. Statt einen kaputten Datensatz wegzuwerfen oder den ganzen Workflow zu blockieren, schiebst du ihn zur Seite. In ein eigenes Google Sheet, in eine Tabelle, in einen separaten Kanal. Dort sammeln sich die Fälle, die Hand brauchen, und der Rest läuft weiter.

In n8n nutzt du dafür am HTTP-Request-Node die Option Continue (using error output). Statt den Workflow abzubrechen, öffnet der Node einen zweiten Ausgang für den Fehlerfall, und an diesen Ausgang hängst du deine Seite-schieben-Logik. In Zapier baust du dir den gleichen Effekt mit Pfaden und der Entscheidung, wie ein Zap mit Fehlern umgeht.

Der Punkt ist immer derselbe. Ein einzelner kaputter Datensatz darf nicht die ganze Maschine anhalten, und er darf auch nicht spurlos verschwinden.

Du musst es mitbekommen, wenn etwas brennt

Das ist die Lektion, die mich der beschwerende Kunde gelehrt hat. Die beste Fehlerbehandlung nützt nichts, wenn du nicht erfährst, dass etwas passiert ist.

Alerting heißt einfach: Wenn ein Workflow scheitert, geht eine Nachricht an dich raus. Eine Mail, eine Telegram-Nachricht, ein Eintrag in einem Slack-Kanal. n8n hat dafür einen eigenen Mechanismus, den du als Fehler-Workflow hinterlegen kannst, sodass bei einem Abbruch automatisch eine Benachrichtigung losgeht. In Zapier kannst du dir per Mail melden lassen, wenn ein Zap auf Fehler-Status geht.

Wichtig ist nur, dass die Nachricht dir konkret sagt, was los war. "Workflow Bestellung fehlgeschlagen" ist halb so wertvoll wie "Workflow Bestellung fehlgeschlagen, Schritt Mailversand, Bestellnummer 4815, Fehler Timeout". Bei der zweiten Variante weißt du sofort, wo du suchen musst.

Und ein ehrlicher Rat aus der Praxis: Mach dein Alerting nicht zu laut. Wenn jeder kleine, sich selbst heilende Retry dir eine Nachricht schickt, schaust du nach drei Tagen nicht mehr hin. Melde die Fälle, die wirklich Hand brauchen, nicht jeden Schluckauf.

Wie du das jetzt angehst

Du musst nicht alles auf einmal bauen. Fang klein an. Geh durch deine bestehende Automation und schalte an jedem Schritt, der mit einem fremden System redet, das Retry an. Drei Versuche, eine Sekunde Pause. Das fängt schon den Großteil der vorübergehenden Fehler ab.

Dann ueberleg dir, welcher Schritt etwas erzeugt, das man nicht doppelt haben darf, und bau dort eine Idempotenz-Prüfung ein. Und zum Schluss richte eine einzige Benachrichtigung ein, die dir sagt, wenn ein Workflow komplett gescheitert ist. Mehr braucht es für den Anfang nicht.

Im Capstone dieses Levels baust du eine vollständige Automation. Nimm das hier mit hinein. Eine Automation, die nur im Schönwetter-Fall funktioniert, ist ein Prototyp. Eine, die auch beim Regen nichts kaputt macht, ist ein Werkzeug.

Quellen

• n8n Retry On Fail, Max Tries und Wait Between Tries, sowie Continue using error output am HTTP Request Node: https://n8nautomationtutorial.com/n8n-http-request-node-retry-on-fail-error-handling-retry-logic
• n8n Community zu den UI-Limits Max Tries 5 und Wait Between Tries 5000 ms: https://community.n8n.io/t/node-max-tries-wait-values-limits-too-low/46284
• Zapier Replay Zap runs: https://help.zapier.com/hc/en-us/articles/8496241726989-Replay-Zap-runs
• Zapier Autoreplay und Fehler-Verhalten (Professional Plan aufwärts): https://help.zapier.com/hc/en-us/articles/14167175792909-Decide-how-your-Zap-handles-errors-with-advanced-settings