- Fehlerarten unterscheiden und passend reagieren
- Wiederholungen so bauen, dass nichts doppelt passiert
- halb erledigte Vorgänge erkennen und behandeln
- stille Ausfälle sichtbar machen
Jeder Ablauf scheitert irgendwann – ein System antwortet nicht, ein Zugang läuft ab, ein Datensatz hat ein unerwartetes Format. Das ist kein Zeichen schlechter Arbeit, sondern normal. Der Unterschied zwischen einem professionellen und einem gebastelten Ablauf liegt nicht darin, ob Fehler auftreten, sondern darin, was dann passiert. Diese Lektion behandelt das Thema, das in Automatisierungsprojekten am häufigsten vergessen wird – und das darüber entscheidet, ob Sie Ihrem Ablauf nach einem halben Jahr noch vertrauen.
1. Fehler sind nicht gleich Fehler
Die Unterscheidung ist wichtig, weil die falsche Reaktion Schaden anrichtet. Ein Ablauf, der bei einem fehlenden Pflichtfeld hundertmal wiederholt, verbraucht das Aufrufkontingent und behebt nichts. Einer, der bei einer kurzen Netzstörung sofort aufgibt, erzeugt unnötige Handarbeit. Als Faustregel gilt: Technische Störungen wiederholen, fachliche Probleme in die Prüfliste, Sicherheits- und Zugangsprobleme sofort melden.
Die Mail konnte nicht zugestellt werden, Postfach voll
Der Ablauf würde eine Rechnung zum zweiten Mal erzeugen
Das Zielsystem antwortet seit einer Stunde nicht
Eine Telefonnummer hat ein unerwartetes Format
2. Wiederholen ohne Schaden
Die wichtigste Regel für Wiederholungen: Derselbe Vorgang darf nicht zweimal wirken. Technisch erreicht man das mit einer eindeutigen Kennung je Vorgang, die der Ablauf mitführt und vor jedem Schritt prüft – existiert der Eintrag mit dieser Kennung schon, wird er nicht erneut angelegt. Diese eine Maßnahme verhindert die unangenehmsten Fehler überhaupt: doppelte Rechnungen, doppelte Bestellungen, dreimal dieselbe Mail an denselben Kunden.
Bei den Abständen hat sich wachsende Wartezeit bewährt: eine Minute, fünf Minuten, eine halbe Stunde, danach melden. So übersteht der Ablauf kurze Störungen von selbst, blockiert aber nicht stundenlang und meldet sich, bevor es jemand von außen bemerkt.
| Angabe | Warum |
|---|---|
| Zeitpunkt und Ablaufname | ordnet den Fehler ein |
| Vorgangskennung | erlaubt die gezielte Wiederholung |
| Fehlermeldung im Original | ohne sie ist die Ursache oft nicht zu finden |
| Eingangsdaten des Vorgangs | damit der Vorgang nachgestellt werden kann |
| Bereits erledigte Schritte | verhindert doppelte Ausführung |
3. Halb erledigte Vorgänge
Der unangenehmste Fall ist der Abbruch mittendrin: Der Kunde ist angelegt, die Bestätigung ist raus, aber die Aufgabe fehlt. Solche Zustände bemerkt niemand, bis sich jemand wundert. Zwei Maßnahmen helfen. Erstens die Reihenfolge: zuerst speichern, dann kommunizieren, damit im Zweifel eher eine Mail fehlt als ein Eintrag. Zweitens eine Zustandsmarkierung am Vorgang – „erfasst“, „bestätigt“, „zugewiesen“. Beim erneuten Lauf sieht der Ablauf, wo er stehen geblieben ist, und macht dort weiter. Das klingt aufwendig, ist aber in den meisten Werkzeugen mit einem zusätzlichen Feld erledigt.
4. Stille Ausfälle
Die gefährlichste Störung erzeugt gar keinen Fehler. Der Ablauf läuft, meldet Erfolg – und tut trotzdem nicht, was er soll. Ursachen sind etwa ein Filter, der nach einer Änderung im Quellsystem nichts mehr findet, oder ein Auslöser, der nicht mehr ausgelöst wird. Dagegen hilft nur eine Erwartungsprüfung: Wenn normalerweise zehn bis dreißig Anfragen am Tag verarbeitet werden und seit zwei Tagen null gezählt wurden, sollte eine Meldung kommen. Diese einfache Regel ist die wirkungsvollste Überwachung überhaupt – Modul 7 vertieft das Thema.
5. Ein Beispiel
Ein Onlinehändler übertrug Bestellungen automatisch in die Buchhaltung. Nach einem Update änderte der Shop das Format des Bestelldatums, der Ablauf lief in einen Fehler – und niemand merkte es, weil die Fehlermeldungen in ein Postfach gingen, das niemand las. Nach elf Tagen fiel beim Monatsabschluss auf, dass über 200 Bestellungen fehlten. Die Nacharbeit dauerte zwei Tage. Danach wurde umgebaut: Fehlermeldungen gehen jetzt in den Team-Chat, es gibt eine tägliche Zusammenfassung mit der Zahl verarbeiteter Bestellungen, und bei null Vorgängen an einem Werktag kommt eine ausdrückliche Warnung. Der Umbau kostete drei Stunden – deutlich weniger als der eine Vorfall.
6. Häufige Fragen
Wohin sollen Fehlermeldungen gehen? Dorthin, wo ohnehin gearbeitet wird – Team-Chat oder ein gemeinsames Postfach mit klarer Zuständigkeit. Ein eigenes Postfach, in das niemand schaut, ist dasselbe wie keine Meldung.
Wie viele Wiederholungen sind sinnvoll? Drei bis vier mit wachsenden Abständen genügen für technische Störungen. Danach gehört ein Mensch informiert – weiter zu versuchen verschleiert nur, dass etwas grundsätzlich nicht stimmt.
Sollen wartende Vorgänge gesammelt werden? Ja. Wenn ein Zielsystem längere Zeit ausfällt, sollten die Vorgänge in einer Warteschlange bleiben und nach der Behebung nachgeholt werden. Verwerfen ist die schlechteste aller Lösungen.
7. Übung zum Selbermachen
Nehmen Sie einen Ablauf, den Sie planen oder bereits nutzen, und gehen Sie jeden Schritt einzeln durch mit der Frage: Was passiert, wenn genau hier etwas schiefgeht? Notieren Sie für jeden Schritt eine der drei Reaktionen – wiederholen, melden, abbrechen. Prüfen Sie zum Schluss, wer die Meldung bekommt und ob diese Person weiß, was dann zu tun ist. Wenn Sie auf diese letzte Frage keine Antwort haben, ist der Ablauf noch nicht fertig.
- [1]n8n (2026): Error Handling und Error Workflows – Dokumentation.
- [2]Google SRE (2017/2024): Site Reliability Engineering – Handling Overload, Retries.
- [3]Nygard, M. (2018): Release It! – Stability Patterns.
Stand: September 2026. Kursmaterial der Klarwerk Akademie. Preise und Funktionsumfang der genannten Werkzeuge ändern sich laufend – maßgeblich sind die Angaben der Anbieter.