Eine Automation, die nur den Gutfall kennt, ist keine Automation, sondern ein Risiko mit Zeitzünder. Netzwerke verlieren Pakete, APIs drosseln Anfragen, Dienste starten neu. Die Frage ist nicht, ob eine externe Schnittstelle ausfällt, sondern wie das eigene System darauf reagiert. Fehlertoleranz ist keine Kür für Konzerne — gerade in KMU-Automationen, wo niemand nachts auf ein Dashboard schaut, entscheidet sie über verlorene Leads, hängende Rechnungsläufe und Datenmüll im CRM.
Timeouts: Die vergessene Grundeinstellung
Der häufigste Fehler ist der fehlende Timeout. Ein Aufruf ohne Zeitlimit wartet im Zweifel unbegrenzt auf eine Antwort, blockiert dabei einen Worker, dann den nächsten, bis der ganze Prozess steht. Ein sinnvoller Timeout richtet sich nach dem, was der Aufruf normalerweise braucht: Antwortet eine API üblicherweise in 300 Millisekunden, sind 5 Sekunden ein großzügiges Limit — 120 Sekunden sind keine Geduld, sondern ein blockierter Prozess. Wichtig ist, dass jeder externe Aufruf ein explizites Limit hat und der Abbruch als definierter Fehler behandelt wird, nicht als Absturz. Sauber getrennt gehören dabei Verbindungs- und Antwort-Timeout: Ob ein Server gar nicht erreichbar ist oder nur langsam antwortet, sind zwei verschiedene Fehlerbilder mit verschiedenen Reaktionen.
Retries mit Exponential Backoff und Jitter
Viele Fehler sind transient: ein kurzer Netzwerkaussetzer, ein Deployment beim Anbieter, ein Rate-Limit. Solche Fehler verschwinden von selbst — ein Retry löst sie. Aber naive Retries, die sofort und in fester Frequenz wiederholen, hämmern auf ein ohnehin überlastetes System ein und machen die Störung schlimmer.
- Exponential Backoff: Die Wartezeit wächst mit jedem Versuch, etwa 1, 2, 4, 8 Sekunden — das Zielsystem bekommt Luft
- Jitter: Eine Zufallskomponente verhindert, dass hunderte Clients synchron im selben Takt wiederholen
- Begrenzte Versuche: Nach einer definierten Zahl von Fehlschlägen ist Schluss, sonst wiederholt das System ewig
- Nur transiente Fehler wiederholen: Ein 429 oder 503 verdient einen Retry, ein 400 mit fehlerhaften Daten nicht
Und weil jeder Retry eine Aktion doppelt auslösen kann, gehören Retries und Idempotenz zusammen: Ein wiederholter Aufruf darf keine zweite Rechnung erzeugen.
Circuit Breaker: Kaskadenfehler stoppen
Wenn ein Dienst länger ausfällt, helfen Retries nicht mehr — sie verlängern nur das Leiden. Der Circuit Breaker funktioniert wie eine Sicherung: Häufen sich Fehler über einen Schwellwert, öffnet er und lässt für eine Abkühlphase gar keine Aufrufe mehr durch. Statt zu warten und zu scheitern, schlagen Anfragen sofort definiert fehl. Nach der Pause prüft der Breaker mit einzelnen Testanfragen, ob das Ziel wieder antwortet, und schließt sich erst dann wieder.
Ein hängender Dienst ist gefährlicher als ein toter: Der tote liefert sofort einen Fehler, der hängende bindet Ressourcen und zieht alle abhängigen Prozesse mit in die Tiefe. Genau davor schützt der Circuit Breaker.
Dead-Letter-Queues: Nichts geht verloren
Was passiert mit dem Auftrag, der alle Retries überlebt hat und trotzdem gescheitert ist? Ohne Konzept: nichts — er verschwindet, und die Rechnung wird nie verschickt. Die Dead-Letter-Queue ist der Auffangbehälter für endgültig gescheiterte Nachrichten. Dort liegen sie mit vollem Fehlerkontext, ein Alert informiert den Verantwortlichen, und nach Korrektur der Ursache lassen sie sich gezielt erneut anstoßen. Der Unterschied ist fundamental: Ein Fehler, der in der DLQ liegt, ist ein Vorgang. Ein Fehler, der still verschwindet, ist ein Datenverlust, den man Wochen später beim Kunden erklärt.
Was das für KMU-Automationen heißt
Diese Muster klingen nach Enterprise-Architektur, betreffen aber jede Zapier-Strecke, jede Webhook-Kette und jede CRM-Anbindung. Ein Lead-Formular, das den CRM-Aufruf ohne Timeout und ohne Retry absetzt, verliert bei jedem API-Schluckauf einen Interessenten — unbemerkt. Ein Rechnungslauf ohne Dead-Letter-Queue produziert Lücken, die erst die Buchhaltung findet. Wer Automationen baut, sollte für jeden externen Aufruf drei Fragen beantworten können: Wie lange warte ich? Wie oft wiederhole ich? Und wo landet der Vorgang, wenn alles scheitert? Systeme, die diese Antworten kennen, fallen nachts nicht um — sie schreiben höchstens ein Protokoll, das man morgens in Ruhe liest.