Fehlerbehandlung und Monitoring: Workflows, die nachts durchlaufen

Das Problem: Workflows, die unbemerkt scheitern

Ein Workflow, der Rechnungen aus E-Mails extrahiert und in DATEV bucht, läuft seit drei Wochen einwandfrei. Dann ändert ein Lieferant sein PDF-Layout, die OCR liefert Null-Werte, und der Workflow bricht ab. Ohne Fehlermeldung. Ohne Nachricht. Drei Tage später fragt die Buchhaltung, warum 14 Rechnungen fehlen.

Oder: Eine Lead-Sequenz soll Kontakte aus dem CRM ziehen, anreichern und Follow-Up-E-Mails verschicken. Die API des CRM-Anbieters liefert plötzlich einen HTTP 429 (Rate Limit), der Workflow stoppt, und 80 Leads bleiben unbearbeitet. Ohne Monitoring bemerkt es niemand, bis der Vertrieb sich über fehlende Termine beschwert.

Automatisierung im Mittelstand rechnet sich nur, wenn Workflows zuverlässig durchlaufen. Dafür brauchen Sie systematische Fehlerbehandlung und aktives Monitoring. Beides ist technisch simpel, wird aber in der Praxis oft vergessen.

Was Fehlerbehandlung bedeutet

Fehlerbehandlung (Error Handling) steuert, was passiert, wenn ein Workflow-Schritt fehlschlägt. Typische Auslöser:

• API liefert HTTP 4xx oder 5xx
• Datenfeld fehlt oder hat falsches Format
• Externe Systeme (CRM, ERP, DATEV) sind nicht erreichbar
• Timeout, weil eine Antwort zu lange dauert
• Rate-Limit überschritten

Ohne explizite Fehlerbehandlung stoppt der Workflow. Mit Fehlerbehandlung entscheiden Sie, ob er abbricht, den Fehler loggt, eine Alternative versucht oder bestimmte Schritte wiederholt.

Plattformen wie n8n, Make und Zapier bieten jeweils eingebaute Mechanismen. In n8n heißt das „Error Workflow”, in Make „Error Handler”, in Zapier „Error Path”. Die Logik ist ähnlich: Sie definieren, was bei einem Fehler geschieht.

Fehlerbehandlung in n8n: Error Workflow und Fallback

In n8n aktivieren Sie für jeden Workflow einen „Error Workflow”. Das ist ein separater Workflow, der ausgeführt wird, sobald irgendein Knoten fehlschlägt. Er erhält automatisch Informationen über den Fehler (Fehlermeldung, betroffener Knoten, Input-Daten).

Typischer Aufbau eines Error Workflow:

1. Fehler-Daten empfangen (automatisch)
2. Fehler kategorisieren: Ist es ein Timeout, ein Datenproblem, ein API-Fehler?
3. Benachrichtigung senden: E-Mail an Admin, Slack-Nachricht, Eintrag in Monitoring-Tool
4. Fehlgeschlagene Daten speichern: In Datenbank, Google Sheet oder CSV ablegen, damit nichts verloren geht
5. Optional: Retry-Logik: Bei Timeout oder Rate-Limit nach 5 Minuten erneut versuchen

Zusätzlich können Sie innerhalb eines Workflows für kritische Knoten einen „On Error” Branch definieren. Beispiel: Schlägt die DATEV-API fehl, speichern Sie die Rechnung stattdessen in einer Warteschlange und buchen manuell nach.

Wichtig: Legen Sie fest, ob der Workflow nach einem Fehler weiterlaufen oder vollständig abbrechen soll. Bei sequenziellen Prozessen (Rechnung buchen) ist ein Abbruch sinnvoll. Bei parallelen Prozessen (100 Leads anreichern) sollten einzelne Fehler den Rest nicht blockieren.

Fehlerbehandlung in Make: Error Handler und Filter

Make bietet für jeden Schritt (Modul) die Option „Add error handler”. Dort definieren Sie, was bei einem Fehler passiert. Typische Patterns:

• Ignore: Fehler wird übersprungen, Workflow läuft weiter (nur bei unkritischen Schritten sinnvoll)
• Retry: Schritt wird nach X Sekunden wiederholt (nützlich bei transienten API-Fehlern)
• Commit: Fehler wird geloggt, Workflow wird als erfolgreich markiert (wenn Teilausfälle akzeptabel sind)
• Rollback: Vorherige Schritte werden rückgängig gemacht (falls möglich)

Kombinieren Sie Error Handler mit einem Filter, der prüft, ob der Fehler kritisch ist. Beispiel: HTTP 503 (Service Unavailable) löst Retry aus, HTTP 401 (Unauthorized) stoppt sofort und sendet Alarm.

Speichern Sie fehlgeschlagene Datensätze in einem Google Sheet oder einer Datenbank. So verlieren Sie nichts und können Fehler nachträglich analysieren.

Monitoring: Wissen, dass es läuft

Fehlerbehandlung fängt Probleme ab. Monitoring stellt sicher, dass Sie überhaupt wissen, ob Workflows laufen, wann sie laufen und ob sie erfolgreich sind.

Drei Monitoring-Ebenen:

1. Plattform-interne Logs: n8n, Make und Zapier zeigen Ausführungshistorie, Erfolg, Fehlerrate und Laufzeit. Prüfen Sie diese täglich oder richten Sie automatische Reports ein.
2. Externe Monitoring-Tools: Uptime-Checks (z. B. UptimeRobot, Better Uptime) pingen einen Webhook an, sobald ein Workflow erfolgreich war. Bleibt der Ping aus, erhalten Sie eine Benachrichtigung.
3. Logging in Datenbank: Schreiben Sie am Ende jedes Workflows einen Eintrag mit Timestamp, Status, verarbeitete Datensätze und Fehlerzahl. Bauen Sie daraus ein Dashboard in Google Data Studio, Metabase oder Grafana.

Konkrete Umsetzung für einen Rechnungs-Workflow:

• Workflow läuft täglich um 6 Uhr
• Schreibt am Ende eine Zeile in ein Google Sheet: Datum, Anzahl verarbeiteter Rechnungen, Anzahl Fehler
• Sendet bei mehr als 3 Fehlern eine E-Mail an die Buchhaltung
• Pingt einen Uptime-Monitor an (falls der Ping ausbleibt, wurde der Workflow nicht ausgeführt)

So sehen Sie auf einen Blick, ob alles läuft, und bekommen aktiv Alarm, wenn etwas schiefgeht.

Retry-Logik: Wann und wie oft wiederholen

Viele Fehler sind transient: API ist kurz überlastet, Netzwerk-Timeout, Rate-Limit. Hier hilft automatisches Wiederholen (Retry).

Best Practices:

• Exponentielles Backoff: Erste Wiederholung nach 1 Minute, zweite nach 5 Minuten, dritte nach 15 Minuten
• Maximale Anzahl: 3 bis 5 Retries, danach Fehler loggen und manuell prüfen
• Idempotenz prüfen: Stellen Sie sicher, dass ein wiederholter Schritt nicht doppelte Buchungen oder E-Mails erzeugt (z. B. durch Prüfung auf eindeutige ID)

In n8n implementieren Sie Retry mit einem Error Workflow, der den ursprünglichen Workflow nach einer Pause erneut triggert und einen Zähler mitführt. In Make nutzen Sie den eingebauten Retry-Mechanismus im Error Handler.

Wann kein Retry sinnvoll ist:

• HTTP 400 (Bad Request): Daten sind fehlerhaft, Wiederholung bringt nichts
• HTTP 401/403 (Unauthorized/Forbidden): Authentifizierung fehlt oder abgelaufen
• Datenvalidierung schlägt fehl: Pflichtfeld fehlt, Format ungültig

Diese Fehler erfordern manuelles Eingreifen. Loggen Sie sie und benachrichtigen Sie den zuständigen Mitarbeiter.

Alerting: Wer wird wie informiert

Monitoring ohne Alerting ist nutzlos. Definieren Sie klare Regeln, wer bei welchem Fehler informiert wird.

Beispiel-Eskalationsmatrix:

• Info-Level (Workflow lief erfolgreich, aber mit Warnungen): Eintrag ins Log, keine aktive Benachrichtigung
• Warning-Level (einzelner Schritt fehlgeschlagen, Workflow hat Fallback genutzt): E-Mail an Fachbereich
• Error-Level (Workflow komplett abgebrochen): E-Mail an Admin und Fachbereich
• Critical-Level (mehrere Workflows betroffen, Plattform nicht erreichbar): Sofort-Benachrichtigung per SMS oder Slack an IT-Verantwortlichen

Nutzen Sie verschiedene Kanäle: E-Mail für Routine-Fehler, Slack oder Microsoft Teams für dringliche Probleme, SMS oder Anruf für kritische Ausfälle.

Wichtig: Vermeiden Sie Alert-Fatigue. Wenn täglich 20 unwichtige E-Mails kommen, werden echte Probleme übersehen. Fassen Sie Infos zusammen (z. B. eine tägliche Zusammenfassung aller Warnungen) und schicken Sie nur wirklich kritische Fehler sofort.

Dashboard und Reports: Der Überblick für die Geschäftsführung

Für die Geschäftsführung zählt nicht jeder einzelne Fehler, sondern die Gesamtverfügbarkeit und der Impact.

Bauen Sie ein einfaches Dashboard mit:

• Anzahl laufender Workflows
• Erfolgsrate letzte 7 Tage (Prozent erfolgreicher Durchläufe)
• Durchschnittliche Laufzeit (zeigt Performance-Probleme)
• Anzahl kritischer Fehler
• Letzte erfolgreiche Ausführung pro Workflow (zeigt, ob ein Workflow „still failed”)

Technisch umgesetzt mit Google Sheets und Data Studio, mit Metabase auf PostgreSQL oder mit Grafana auf InfluxDB. Die Daten kommen aus den Workflow-Logs, die Sie automatisch schreiben.

Schicken Sie der Geschäftsführung einmal pro Woche einen automatischen Report: „Alle 12 Workflows liefen erfolgreich, 3 Warnungen (Details im Anhang), keine kritischen Ausfälle.” So entsteht Vertrauen in die Automatisierung.

Was nicht funktioniert

• Nur auf Plattform-Logs verlassen: Wenn die Plattform selbst ausfällt, sehen Sie nichts
• Keine Benachrichtigung bei fehlendem Workflow-Start: Ein Workflow, der nicht läuft, wirft keinen Fehler. Ohne Uptime-Check bemerken Sie es nicht
• Fehler ignorieren, „weil es meistens klappt”: Ein Workflow, der in 5 Prozent der Fälle scheitert, verliert pro Jahr hunderte Datensätze
• Zu viele Alerts: Führt dazu, dass Benachrichtigungen ignoriert werden
• Keine Dokumentation der Fehlerbehandlung: Wenn der Admin wechselt, weiß niemand, wie Fehler eskaliert werden

Checkliste für produktionsreife Workflows

Bevor Sie einen Workflow unbeaufsichtigt laufen lassen:

1. Error Workflow oder Error Handler konfiguriert?
2. Fehlgeschlagene Daten werden gespeichert?
3. Retry-Logik für transiente Fehler aktiv?
4. Benachrichtigung bei kritischen Fehlern eingerichtet?
5. Uptime-Check pingt bei erfolgreicher Ausführung?
6. Logging in Datenbank oder Sheet aktiv?
7. Dashboard zeigt Status und Erfolgsrate?
8. Eskalationsmatrix dokumentiert (wer wird wann informiert)?

Wenn Sie alle Punkte abhaken können, läuft Ihr Workflow auch nachts, am Wochenende und im Urlaub.

Fazit: Automatisierung, die Sie schlafen lässt

Fehlerbehandlung und Monitoring sind keine optionalen Add-ons. Sie sind der Unterschied zwischen einer Spielerei und einem produktiven System, das dem Mittelstand echten Nutzen bringt.

Ein Workflow, der unbemerkt scheitert, kostet mehr, als er spart. Ein Workflow, der Fehler abfängt, loggt, meldet und im Zweifel selbst korrigiert, arbeitet zuverlässiger als jeder Mensch.

Die Technik ist einfach. Die Plattformen liefern die Werkzeuge. Sie müssen sie nur konsequent einsetzen.

Wenn Sie Workflows aufbauen oder bestehende absichern möchten, sprechen Sie mit uns.

Sprechen Sie mit uns

Sie möchten das in Ihrem Betrieb umsetzen? Wir bauen die passende Maschine mit Ihnen.

Telefon: 040 468 967 680
E-Mail: info@whitefox-automations.com
Oder über unser Kontaktformular.