Fehlerbehandlung in Automatisierungen: Retries, Fallbacks und Idempotenz

Ein Automatisierungs-Workflow, der zehnmal fehlerfrei läuft und beim elften Mal eine Bestellung doppelt anlegt oder eine Rechnung verschluckt, ist kein Randfall – er ist der Normalfall unfertiger Automatisierung. Die meisten Workflows werden für den Happy Path gebaut: Alle Systeme antworten, alle Daten sind vollständig, nichts hakt. In der Praxis stimmt das nur einen Teil der Zeit. APIs sind kurzzeitig nicht erreichbar, Formulare liefern unvollständige Daten, ein Drittsystem antwortet mit Verzögerung. Was dann passiert, entscheidet, ob eine Automatisierung Vertrauen aufbaut oder nach dem ersten Vorfall wieder abgeschaltet wird.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die Automatisierungen einsetzen oder planen – von der No-Code-Verkettung bis zur Integration mit KI-Bausteinen. Er beantwortet die zentralen Fragen der Fehlerbehandlung: welche Fehlerklassen es gibt, wann Retries helfen, was Idempotenz bedeutet, wie Fallbacks aufgebaut werden und wie man doppelte Aktionen verhindert. Grundlagen zur Automatisierung selbst behandelt die Kategorieseite Prozessautomatisierung.

Begriffe kurz geklärt

Vier Begriffe tauchen in diesem Artikel ständig auf und werden oft durcheinandergeworfen:

• Transienter Fehler – ein Fehler, der von einer vorübergehenden Störung stammt (Netzwerk, Serverlast, Zeitüberschreitung) und sich typischerweise innerhalb von Sekunden bis Minuten von selbst löst.
• Retry (Wiederholungsversuch) – ein erneuter Versuch derselben Operation nach einem Fehler, meist mit Wartezeit dazwischen.
• Idempotenz – die Eigenschaft einer Operation, bei mehrfacher identischer Ausführung dasselbe Ergebnis zu liefern wie bei einmaliger Ausführung.
• Fallback – ein definierter Ersatzweg, der greift, wenn die eigentliche Operation auch nach Wiederholungsversuchen nicht gelingt.

Diese vier Konzepte sind keine akademische Übung. Sie sind der Unterschied zwischen einer Automatisierung, die nachts unbeaufsichtigt laufen darf, und einer, die jeden Morgen von Hand nachkontrolliert werden muss.

Welche Fehlerklassen gibt es?

Bevor irgendeine Fehlerbehandlung gebaut wird, muss klar sein, mit welcher Art von Fehler man es zu tun hat – denn die drei Klassen brauchen fundamental unterschiedliche Reaktionen.

1. Transiente Fehler. Kurzzeitige, sich selbst lösende Störungen: ein Zeitüberschreitungsfehler bei einer API, eine kurzfristig überlastete Datenbank, eine Ratenbegrenzung (Rate Limit), die nach wenigen Sekunden wieder Kapazität freigibt. Laut Azure Architecture Center sollten solche Fehler in Cloud-Umgebungen als Normalfall erwartet und die Anwendung entsprechend gestaltet werden, statt sie als Ausnahme zu behandeln. Die richtige Reaktion: erneut versuchen, mit Wartezeit.

2. Dauerhafte (persistente) Fehler. Ein System ist wirklich nicht erreichbar (Ausfall, Wartungsfenster, falsche Zugangsdaten), eine Konfiguration ist fehlerhaft, oder ein Dienst wurde abgeschaltet. Hier hilft Wiederholen nicht – im Gegenteil: Laut Azure Architecture Center sollte eine Anwendung eine Operation, die wahrscheinlich fehlschlägt, gerade nicht endlos wiederholen, sondern den Fehler erkennen und entsprechend behandeln. Die richtige Reaktion: Fallback, Eskalation, Alarmierung.

3. Fachliche Fehler. Die Anfrage selbst ist ungültig – ein Pflichtfeld fehlt, ein Format stimmt nicht, ein referenzierter Datensatz existiert nicht. Ein Retry mit denselben Daten liefert exakt dasselbe Ergebnis noch einmal: den Fehler. Die richtige Reaktion: Daten korrigieren (automatisiert oder durch einen Menschen), nicht wiederholen.

Der häufigste Fehler in selbstgebauten Automatisierungen ist, alle drei Klassen gleich zu behandeln – meist mit derselben pauschalen „bei Fehler dreimal wiederholen”-Logik. Das führt dazu, dass transiente Fehler zu selten und fachliche Fehler sinnlos oft wiederholt werden.

Wann sind Retries sinnvoll?

Retries sind sinnvoll, wenn zwei Bedingungen erfüllt sind: Der Fehler ist wahrscheinlich transient, und die wiederholte Operation ist sicher auszuführen (dazu mehr im Abschnitt zu Idempotenz). Typische Kandidaten sind Netzwerkfehler, Zeitüberschreitungen, HTTP-Statuscodes wie 429 (zu viele Anfragen) oder 503 (Dienst nicht verfügbar).

Drei Elemente gehören laut Azure Architecture Center zu einer robusten Retry-Strategie:

• Eine Obergrenze für Versuche. Endlose Wiederholungen sind keine Fehlerbehandlung, sondern eine neue Fehlerquelle – sie binden Ressourcen und können ein bereits überlastetes System weiter belasten.
• Wachsender Abstand zwischen Versuchen (Backoff). Sofortiges, wiederholtes Anfragen verschärft genau das Problem, das den Fehler oft verursacht hat: Überlast. Ein wachsender Abstand gibt dem Zielsystem Zeit zur Erholung.
• Abbruch bei eindeutig dauerhaften Fehlern. Nicht jeder Fehlercode rechtfertigt einen Retry. Ein Authentifizierungsfehler oder ein „Datensatz nicht gefunden” wird durch Wiederholen nicht besser.

Für Fälle, in denen ein Zielsystem über längere Zeit ausfällt, empfiehlt die Azure-Dokumentation, das Retry Pattern mit dem sogenannten Circuit-Breaker-Muster zu kombinieren: Nach einer bestimmten Zahl aufeinanderfolgender Fehlschläge schaltet der „Schutzschalter” in einen offenen Zustand, in dem Anfragen sofort abgelehnt werden, statt jede einzeln bis zum Timeout laufen zu lassen. Nach einer Wartezeit lässt der Schalter testweise wieder einzelne Anfragen durch (Halb-offen) und schließt sich erst wieder vollständig, wenn diese erfolgreich sind. Das verhindert, dass eine Automatisierung minutenlang gegen ein erkennbar ausgefallenes System anrennt und dabei Warteschlangen verstopft.

Meine Faustregel aus der Praxis: Für Standard-Integrationen zwischen SaaS-Tools reichen meist zwei bis drei Versuche mit steigendem Abstand (z. B. Sekunden, dann Zehner-Sekunden-Bereich), bevor der Fallback greift. Bei Anbindungen an Systeme mit bekannt längeren Wartungsfenstern lohnt sich ein separater, deutlich großzügigerer Zeitrahmen – aber das ist eine Annahme aus konkreten Projekten, keine allgemeingültige Zahl, und gehört pro Integration einzeln geprüft.

Was bedeutet Idempotenz?

Eine Operation ist idempotent, wenn das mehrfache identische Ausführen zum selben Endzustand führt wie das einmalige Ausführen. Ein Löschbefehl für einen bereits gelöschten Datensatz ist idempotent: Der Zustand „gelöscht” ändert sich beim zweiten Aufruf nicht. Ein „Neue Bestellung anlegen”-Befehl ist es von Natur aus nicht: Jeder Aufruf legt einen neuen Datensatz an, auch wenn es inhaltlich derselbe Vorgang ist.

Das ist der Kern des Problems bei Retries: Ein Retry setzt voraus, dass die wiederholte Ausführung sicher ist. Bei nicht-idempotenten Operationen – vor allem beim Anlegen von Datensätzen, Versenden von Nachrichten oder Auslösen von Zahlungen – ist genau das nicht gegeben. Ein Retry nach einem Zeitüberschreitungsfehler kann eine Operation wiederholen, die in Wahrheit schon erfolgreich war, nur die Bestätigung ist nicht angekommen. Ergebnis: Dublette.

Die Standardlösung dafür sind Idempotenzschlüssel. Stripe beschreibt das Prinzip in der eigenen API-Dokumentation so: Ein Client erzeugt einen eindeutigen Schlüssel für einen Vorgang; der Server merkt sich das Ergebnis der ersten Ausführung zu diesem Schlüssel; jede weitere Anfrage mit demselben Schlüssel bekommt exakt dasselbe Ergebnis zurück, statt die Operation erneut auszuführen – unabhängig davon, ob die erste Anfrage erfolgreich war oder fehlgeschlagen ist. Stripe empfiehlt dafür zufällige, kollisionsarme Werte (etwa UUIDs) und begrenzt Schlüssel auf 255 Zeichen; Idempotenzschlüssel dürfen laut Stripe zudem keine sensiblen Daten wie E-Mail-Adressen enthalten.

Für eigene Automatisierungen lässt sich dasselbe Prinzip auch ohne fertige API-Unterstützung des Zielsystems nachbauen: eine fachliche, eindeutige Kennung pro Vorgang (z. B. Bestellnummer plus Zeitstempel der Auslösung, oder ein Hash aus den relevanten Feldern) vor jeder schreibenden Aktion gegen einen Verlauf abgleichen. Ist die Kennung schon bekannt, wird nicht erneut geschrieben, sondern das vorhandene Ergebnis zurückgegeben oder der Schritt übersprungen.

Wie baut man Fallbacks?

Ein Fallback ist die Antwort auf die Frage: Was passiert, wenn alle sinnvollen Retries ausgeschöpft sind und der Fehler weiterhin besteht? Ohne definierten Fallback endet ein Workflow in einem von zwei schlechten Zuständen: Er bricht ab und der Vorgang verschwindet unbemerkt, oder er läuft in einem undefinierten Zustand weiter und produziert Folgefehler.

Drei Fallback-Strategien decken die meisten Fälle ab:

Strategie	Wann sinnvoll	Beispiel
Ersatzweg	Es gibt eine alternative Methode, dasselbe Ziel zu erreichen	E-Mail-Versand über einen zweiten Anbieter, wenn der erste nicht antwortet
Warteschlange für Nachbearbeitung	Der Vorgang ist nicht zeitkritisch, kann aber nicht sofort abgeschlossen werden	Fehlgeschlagene Datensätze landen in einer Ablage und werden per separatem Lauf erneut verarbeitet
Eskalation an einen Menschen	Der Vorgang ist zeitkritisch oder fachlich zu unklar für automatische Korrektur	Eine Bestellung mit widersprüchlichen Daten geht als Aufgabe an das zuständige Team

Eigene Einordnung Philogic Labs, aus Umsetzungsprojekten mit No-Code- und API-basierten Automatisierungen.

Wichtig bei allen drei Varianten: Der Fallback selbst muss protokolliert werden – wer oder was hat wann welchen Vorgang auf welchem Weg abgeschlossen. Ein Fallback, der stillschweigend greift, verschiebt das Problem nur von „Workflow bricht sichtbar ab” zu „niemand merkt, dass hier ein Sonderweg gelaufen ist”. Gerade bei der Eskalation an Menschen gehört dazu auch, dass die Aufgabe eine erkennbare Frist und einen klaren Empfänger hat – sonst bleibt sie liegen wie jede andere unpriorisierte Aufgabe auch.

Ein Grenzfall verdient besondere Aufmerksamkeit: Wenn kein Fallback möglich ist – etwa weil es keinen Ersatzweg gibt und der Vorgang zeitkritisch ist –, ist die ehrliche Antwort manchmal, den Workflow so zu gestalten, dass er in diesem Fall früh und deutlich meldet, statt einen Fallback zu erzwingen, der selbst wieder Fehler produziert.

Wie verhindert man doppelte Aktionen?

Doppelte Aktionen entstehen fast immer an derselben Stelle: zwischen „Operation ausgeführt” und „Bestätigung erhalten”. Fällt die Bestätigung aus – wegen eines Netzwerkfehlers, einer Zeitüberschreitung oder eines Systemabsturzes –, weiß der aufrufende Workflow nicht, ob die Operation wirklich fehlgeschlagen ist oder nur die Antwort verloren ging. Ein naiver Retry wiederholt in diesem Fall eine bereits erfolgreiche Operation.

Drei Bausteine verhindern das in der Praxis:

1. Idempotenzschlüssel pro Vorgang, wie im vorherigen Abschnitt beschrieben – entweder vom Zielsystem unterstützt (wie bei der Stripe-API) oder selbst gebaut über einen Abgleich gegen eine Verlaufstabelle.
2. Prüfen vor Schreiben. Vor jeder anlegenden oder ändernden Aktion einen Blick in das Zielsystem werfen: Existiert der Datensatz mit dieser fachlichen Kennung schon? Diese Prüfung kostet einen zusätzlichen Schritt, spart aber jede nachträgliche Dublettenbereinigung.
3. Deduplizierung anhand fachlicher Kennungen, nicht Zeitstempeln. Zwei Aufrufe im Abstand von Millisekunden mit identischer Bestellnummer sind derselbe Vorgang, auch wenn ihre Zeitstempel sich unterscheiden. Wer stattdessen nach Zeitfenstern dedupliziert, übersieht echte Duplikate und blockiert manchmal fälschlich echte Folgevorgänge.

Diese drei Bausteine ersetzen sich nicht gegenseitig – ein sauberer Workflow kombiniert sie: Idempotenzschlüssel als technische Absicherung, Prüfen-vor-Schreiben als fachliche Absicherung, korrekte Deduplizierungslogik als drittes Sicherheitsnetz.

Umsetzung: Ablauf und eigenes Muster

Zusammengefasst ergibt sich aus den vorherigen Abschnitten ein wiederkehrender Ablauf, den ich in eigenen Umsetzungsprojekten als Grundgerüst verwende. Als Ablaufdiagramm in Textform:

Start: Operation X ausführen
  │
  ▼
Idempotenzschlüssel für diesen Vorgang bekannt?
  ├─ Ja → Ergebnis des vorherigen Laufs zurückgeben, KEIN erneutes Schreiben
  └─ Nein → weiter
          │
          ▼
      Operation X ausführen, Ergebnis abwarten
          │
          ▼
      Erfolgreich? ── Ja → Ergebnis + Idempotenzschlüssel protokollieren, Ende
          │
          Nein
          ▼
      Fehlerklasse bestimmen
          ├─ Fachlicher Fehler → Vorgang NICHT wiederholen, an Korrektur/Mensch geben, Ende
          ├─ Dauerhafter Fehler → Retry-Zähler ignorieren, direkt zu Fallback
          └─ Transienter Fehler → weiter
                  │
                  ▼
              Retry-Zähler < Obergrenze?
                  ├─ Ja → Wartezeit (wachsend), Retry-Zähler +1, zurück zu "Operation X ausführen"
                  └─ Nein → weiter zu Fallback
                          │
                          ▼
                      Fallback: Ersatzweg / Warteschlange / Eskalation
                          │
                          ▼
                      Fallback-Ergebnis protokollieren, Ende

Als Pseudocode, technologieunabhängig:

funktion verarbeiteVorgang(vorgang):
    schluessel = erzeugeIdempotenzschluessel(vorgang)
    wenn bereitsVerarbeitet(schluessel):
        return geladenesErgebnis(schluessel)

    versuch = 0
    obergrenze = 3
    wartezeit = 2  # Sekunden, verdoppelt sich je Versuch

    solange versuch < obergrenze:
        ergebnis = fuehreAus(vorgang)

        wenn ergebnis.erfolgreich:
            protokolliere(schluessel, ergebnis)
            return ergebnis

        fehlerklasse = klassifiziere(ergebnis.fehler)

        wenn fehlerklasse == "fachlich":
            eskaliereAnMensch(vorgang, ergebnis.fehler)
            return ergebnis  # kein Retry

        wenn fehlerklasse == "dauerhaft":
            abbrechen  # Schleife verlassen, direkt zu Fallback

        # transienter Fehler: erneut versuchen
        warte(wartezeit)
        wartezeit = wartezeit * 2
        versuch = versuch + 1

    ergebnis = fuehreFallbackAus(vorgang)
    protokolliere(schluessel, ergebnis, fallback = wahr)
    return ergebnis

Dieses Muster ist bewusst so gehalten, dass es sich sowohl in No-Code-Tools mit Bedingungen und Schleifen als auch in individuell entwickelten Integrationen abbilden lässt. In No-Code-Umgebungen fehlt oft eine native Idempotenzprüfung – dann übernimmt eine einfache Tabelle oder Datenbank mit bereits verarbeiteten Kennungen genau diese Funktion.

Bei der Umsetzung entscheidet sich viel daran, wie gut Fehler überhaupt sichtbar gemacht werden. Ein Workflow, der Fehler nur intern verschluckt, lässt sich nicht verbessern, weil niemand merkt, wo es hakt. Wie man Automatisierungen dafür laufend beobachtet, behandelt ein eigener Artikel dieses Clusters zum Thema Workflow-Monitoring.

Risiken & Grenzen

Fehlerbehandlung löst nicht jedes Problem, und sie kann selbst neue Risiken erzeugen, wenn sie falsch gebaut ist:

• Retries ohne Obergrenze verschärfen Ausfälle. Ein System, das gerade überlastet ist, wird durch aggressive, unbegrenzte Wiederholungsversuche vieler paralleler Workflow-Läufe eher noch stärker belastet – ein Effekt, den das Circuit-Breaker-Muster gezielt adressiert.
• Idempotenz ist nicht automatisch gegeben. Viele Standard-APIs und No-Code-Konnektoren unterstützen keine Idempotenzschlüssel von sich aus. Wo das fehlt, muss die Absicherung selbst gebaut werden – das ist zusätzlicher Aufwand, der oft unterschätzt wird.
• Fallbacks können falsche Sicherheit erzeugen. Ein Fallback, der „irgendwie” durchläuft, ohne dass jemand die Ursache des ursprünglichen Fehlers klärt, verdeckt ein wiederkehrendes Problem, statt es zu lösen. Fallback-Häufigkeit gehört beobachtet, nicht nur toleriert.
• Nicht jeder Fehler gehört automatisiert behandelt. Bei Vorgängen mit hohem Schaden im Fehlerfall (Zahlungen, rechtlich bindende Erklärungen, sensible personenbezogene Daten) ist eine bewusste manuelle Prüfstufe oft die richtigere Antwort als ein möglichst cleverer automatischer Fallback.
• Komplexität hat einen Preis. Retry-Logik, Idempotenzprüfung und Fallback-Pfade machen einen Workflow schwerer verständlich und wartbar. Für unkritische, seltene Vorgänge kann eine einfache Fehlermeldung mit manueller Nachbearbeitung die angemessenere Lösung sein als ein aufwendig abgesichertes automatisches System.

Und eine Grenze dieses Artikels selbst: Die konkrete Ausgestaltung – wie viele Retries, welche Wartezeiten, welcher Fallback – hängt am jeweiligen System, seiner Fehlerhäufigkeit und dem Schaden im Fehlerfall. Pauschale Werte dafür gibt es nicht, nur Prinzipien. Wer eine bestehende Automatisierung auf genau diese Fragen hin durchleuchten will: Ein Erstgespräch klärt in kurzer Zeit, wo die größten Lücken liegen, und unser Beratungsangebot begleitet die Umsetzung. Wo Fehlerbehandlung Teamwissen statt Einzelentscheidung sein soll, helfen zudem gezielte Schulungen für die Personen, die Automatisierungen im Alltag betreuen.

Checkliste: Fehlerbehandlung in Automatisierungen

1. Jeder Workflow-Schritt, der scheitern kann, ist einer der drei Fehlerklassen zugeordnet (transient, dauerhaft, fachlich).
2. Retries sind nur für transiente Fehler aktiv, mit fester Obergrenze und wachsender Wartezeit zwischen den Versuchen.
3. Bei wiederholt dauerhaftem Ausfall eines Zielsystems greift ein Mechanismus, der weitere sofortige Versuche stoppt (Circuit-Breaker-Prinzip), statt endlos gegen das ausgefallene System zu laufen.
4. Jede schreibende Aktion (Anlegen, Ändern, Versenden, Zahlen) hat eine Idempotenzabsicherung – über eine unterstützte API-Funktion oder eine selbst gebaute Kennungsprüfung.
5. Für jeden Workflow ist definiert, was im Fehlerfall nach ausgeschöpften Retries passiert: Ersatzweg, Warteschlange oder Eskalation an einen Menschen.
6. Fallback-Vorgänge werden protokolliert und sind von normal abgeschlossenen Vorgängen unterscheidbar.
7. Fachliche Fehler landen nicht in der Retry-Schleife, sondern gehen direkt zur Korrektur.
8. Die Häufigkeit von Retries und Fallbacks wird beobachtet – häufige Fallback-Nutzung ist ein Signal für ein ungelöstes Grundproblem, kein Dauerzustand.
9. Für Vorgänge mit hohem Schaden im Fehlerfall existiert bewusst eine manuelle Prüfstufe statt eines rein automatischen Fallbacks.

Weiterführend zu den Grundlagen der Automatisierung, zur Auswahl geeigneter Prozesse und zur laufenden Beobachtung von Workflows: die weiteren Artikel im Cluster Prozessautomatisierung.