Stille Fehler: woran Sie merken, dass ein Ablauf nicht läuft

Sie merken es nur an dem, was Sie vorher eingerichtet haben: an einer Fehlermeldung, an einem Lebenszeichen und an einer Zählprobe. Dazu gehört, dass schriftlich feststeht, wer das jeweils prüft. Ein Ablauf, im Fachwort Workflow, ist eine Kette von Schritten, die ein Programm nach einem Auslöser von allein abarbeitet, etwa nach dem Eingang einer Formularanfrage. Er meldet sich nur dann, wenn jemand vorher eine Meldung eingerichtet hat und die Meldung bei einem Menschen landet, der sie liest. Stand aller Herstellerangaben: November 2026.

Drei Arten, wie ein Ablauf still ausfällt

Art	Was ist passiert	Was meldet sich von selbst
Gemeldeter Fehler	Ein Schritt scheitert, zum Beispiel weil ein Zugang abgelaufen ist	Eine Meldung, wenn sie eingerichtet ist
Erfolg ohne Ergebnis	Der Fehler wurde abgefangen, oder der Schritt fand nichts, und die Ausführung gilt trotzdem als gelungen	Meist nichts
Nie gestartet	Der Auslöser sprang nicht an, oder der Ablauf wurde abgeschaltet	Meist nichts, weil keine Ausführung scheitert

Was die Werkzeuge selbst melden, unterscheidet sich je Hersteller. Die folgenden Angaben stammen aus deren Dokumentation, der Wortlaut steht jeweils im Original.

Was als Fehler und was als Erfolg zählt

Bei n8n, einem verbreiteten Werkzeug für solche Abläufe, wählen Sie in den Einstellungen jedes einzelnen Ablaufs einen Fehler-Workflow aus. Er „runs if an execution fails“ und muss mit dem Baustein „Error Trigger“ beginnen. Sie können ihn für mehrere Abläufe nutzen und darin etwa eine Mail verschicken. Der Fehler-Workflow lässt sich beim Ausprobieren nicht auslösen: „The Error Trigger only runs when an automatic workflow errors.“ Und scheitert schon der Auslöser selbst, fehlen in der Meldung Ausführungsnummer und Link. Mit dem Baustein „Stop And Error“ können Sie eine Ausführung bewusst scheitern lassen. So ließe sich ein leeres Ergebnis zu einem gemeldeten Fehler machen. Diese Anwendung ist eine Idee des Autors, keine Angabe des Herstellers.

Bei einzelnen Bausteinen steht „On Error“ mit der Wahl „Continue“: „Proceeds to the next node despite the error, using the last valid data.“ Wie n8n eine solche Ausführung zählt, sagt die Dokumentation nicht. Ein Forenbeitrag vom 1. August 2026 (Einzelbericht, von n8n nicht bestätigt) berichtet, solche Läufe erschienen als erfolgreich, der Fehler stehe nur in den Ausführungsdaten.

Bei Make ist es ausdrücklich beschrieben. Der Fehlerbehandler „Skip“ „marks the run as successful, even if an error occurs“, „Resume“ endet mit dem Status „Success“, „Retry“ mit „Warning“. Ohne Behandlung endet der Lauf mit einem Fehler. Nach standardmäßig drei Fehlläufen in Folge schaltet Make den Ablauf ab und schickt dazu eine E-Mail.

Bei Zapier gilt ein Lauf nur als „Successful“, wenn alle Schritte erfolgreich waren. Ein abgefangener Fehler heißt „Handled error“. Dann schaltet Zapier den Ablauf nicht automatisch ab, und laut Hilfeseite verschickt es keine Fehlermails, solange ein Fehlerbehandler läuft. Enden dagegen in sieben Tagen 95 Prozent der Läufe mit einem Fehler, schaltet Zapier den Ablauf aus.

Wer Fehler abfängt, muss die Meldung selbst einbauen.

Wiederholen hilft, kann aber doppelt buchen

Bei n8n steht in den Bausteineinstellungen „Retry On Fail“: „When an execution fails, the node reruns until it succeeds.“ Die Seite zum HTTP-Baustein nennt dazu „Max Tries“ und „Wait Between Tries (ms)“, die Zahl der Versuche und die Pause lassen sich also einstellen. Beim manuellen Wiederholen aus der Ausführungsliste verarbeitet der gescheiterte Baustein laut Dokumentation alle Einträge noch einmal, auch die, die er vor dem Fehler schon erledigt hatte: „a node that sent some messages before it failed sends those messages again.“ Prüfen Sie vorher im Zielprogramm, was schon angekommen ist. Eine erfolgreiche Ausführung lässt sich nicht wiederholen, auch wenn sie nichts bewirkt hat. Und wiederholen können Sie nur, solange n8n die Ausführung noch speichert. Bei Selbstbetrieb löscht die Standardeinstellung nach 336 Stunden, das sind 14 Tage. Wer nur monatlich nachsieht, findet dann keine Fehler mehr.

Make wiederholt von selbst drei Fehlerarten: Ratenbegrenzung, Verbindungsfehler und Zeitüberschreitung. Voraussetzung ist die Speicherung unvollständiger Ausführungen, und die ist ausgeschaltet: „Incomplete executions are disabled by default.“ Ist sie an, plant Make acht Versuche ein, den ersten nach einer Minute und den letzten nach 7 Stunden und 51 Minuten. Alle anderen Fehler wiederholt Make nur über den Fehlerbehandler „Retry“, der dieselbe Speicherung braucht und laut Dokumentation bei eingeschalteter automatischer Fortsetzung standardmäßig 3 Versuche mit 15 Minuten Pause macht.

Ob ein Schritt wiederholt werden darf, ist eine Frage an Ihr Fach: Darf dieselbe Bestätigung zweimal an einen Kunden gehen? Die Antwort gehört auf den Zettel.

Lebenszeichen und Zählprobe

Ein Lebenszeichen ist ein Signal, dass ein Ablauf in der erwarteten Zeit gelaufen ist. Bleibt es aus, schlägt jemand Alarm.

Die Gesundheitsprüfung von n8n sieht nur den Server. „/healthz“ liefert 200, wenn die Instanz erreichbar ist, und „doesn’t indicate DB status“. „/healthz/readiness“ prüft zusätzlich die Datenbank. Ob ein einzelner Ablauf läuft, sagen beide nicht.

Dass ein Ablauf trotz „veröffentlicht“ nicht läuft, ist bei n8n sogar ein beschriebener Zustand. Bei „Published, partial“ ist mindestens ein Auslöser nicht angesprungen, und „n8n doesn’t unpublish it“. Bei „Failed to publish“ gilt: „None of the workflow’s triggers activated, so the workflow isn’t running.“ Ist weder für den Ablauf noch für die Instanz eine Zeitzone eingestellt, rechnet n8n laut Dokumentation mit New York (EDT), ein Zeitplan läuft dann mehrere Stunden versetzt zur deutschen Zeit.

Ein Forenbeitrag vom 1. August 2026 (Einzelbericht) schlägt einen Wächter-Ablauf nach Zeitplan vor. Er fragt über die öffentliche Schnittstelle von n8n den Zeitpunkt der letzten Ausführung je Ablauf ab und vergleicht ihn mit dem erwarteten Zeitfenster. Ob ein Ablauf noch als aktiv geführt wird, prüft er ebenfalls. Ein zweiter Beitrag vom 2. August ergänzt, dass ein nie aktivierter Ablauf gar keine Ausführung hat, an der sich eine Lücke zeigen könnte. Die Schnittstelle gibt es laut Dokumentation bei Selbstbetrieb in allen Ausgaben, in der Cloud ab dem Starter-Tarif. Das ist keine gemessene Lösung.

Einfacher und ohne Technik ist die Zählprobe, ein Vorschlag des Autors: Sie vergleichen eine Zahl am Anfang mit einer Zahl am Ende. Beim Anfragenformular sind das die Eingänge im Postfach gegen die Einträge in der Anfragenliste. Weicht die Zahl ab, ist etwas still ausgefallen, auch wenn jede Ausführung „erfolgreich“ hieß.

Beispiel mit erfundenen Daten

Ein Betrieb bekommt 30 Terminanfragen im Monat über ein Formular, also eine je Tag (30 geteilt durch 30). Ein Zugang läuft ab, der Ablauf legt keine Einträge mehr an.

Die Zahlen der Grafik sind Annahmen. Ohne Überwachung fällt der Ausfall beim gemeldeten Fehler nach 5 Tagen auf, beim nie gestarteten Ablauf nach 14 und beim Erfolg ohne Ergebnis erst nach 30 Tagen. Mit Überwachung sind es 1, 1 und 7 Tage: Fehlermeldung am selben Tag, tägliches Lebenszeichen, wöchentliche Zählprobe.

ohne Überwachungmit Überwachung

• Gemeldeter FehlerAnnahme, Fehlermeldung am Tag selbst

  ohne Überwachung 5 Tage
  mit Überwachung 1 Tage

• Ablauf nie gestartetAnnahme, tägliches Lebenszeichen

  ohne Überwachung 14 Tage
  mit Überwachung 1 Tage

• Erfolg ohne ErgebnisAnnahme, wöchentliche Zählprobe

  ohne Überwachung 30 Tage
  mit Überwachung 7 Tage

Quelle: Beispiel mit erfundenen Daten, Annahmen des Autors, nicht gemessen

Textfassung der Grafik

• Gemeldeter Fehler: ohne Überwachung 5 Tage, mit Überwachung 1 Tage (Annahme, Fehlermeldung am Tag selbst)
• Ablauf nie gestartet: ohne Überwachung 14 Tage, mit Überwachung 1 Tage (Annahme, tägliches Lebenszeichen)
• Erfolg ohne Ergebnis: ohne Überwachung 30 Tage, mit Überwachung 7 Tage (Annahme, wöchentliche Zählprobe)
• Quelle: Beispiel mit erfundenen Daten, Annahmen des Autors, nicht gemessen

Bei einer Anfrage je Tag sind 7 Tage bis zur Entdeckung bis zu 7 unbearbeitete Anfragen. Eine tägliche Zählprobe verkürzt das auf 1 Tag. Setzen wir als Annahme 2 Minuten je Prüfung an, kostet sie 5 mal 2 Minuten, also 10 Minuten je Arbeitswoche.

Wer liest die Meldung

Zapier schickt Fehlermeldungen laut Hilfeseite standardmäßig an die E-Mail-Adresse des Zapier-Kontos. Wer hat dieses Konto angelegt? Ist es eine ausgeschiedene Kraft oder ein Dienstleister, geht die Meldung ins Leere. Bei n8n bestimmt Ihr Fehler-Workflow den Empfänger. Wie Make den Empfänger festlegt, habe ich nicht geprüft. Eine Gruppenadresse des Büros mit benannter Vertretung ist robuster als die Mail einer Einzelperson. Das ist eine Empfehlung des Autors und keine Herstellervorgabe.

Fehlertexte können Kundendaten enthalten. n8n bietet laut Dokumentation eine Schwärzung der Ausführungsdaten (Redaction); ihre Verfügbarkeit je Tarif habe ich nicht geprüft. Schicken Sie in der Meldung lieber nur Ablaufname und Link. Welche Daten in welches Werkzeug dürfen, steht in Datenzonen. Im Einzelfall klärt das Ihr Datenschutzbeauftragter.

Auf den Zettel je Ablauf, eine Seite, gehören:

• Name, Zweck und erwartete Häufigkeit, zum Beispiel „30 Anfragen im Monat“
• Empfänger der Fehlermeldung, Vertretung und Frist zum Reagieren
• Wiederholung ja oder nein, mit dem Risiko doppelter Mails oder Buchungen
• Zählprobe: welche Zahl gegen welche, wer prüft, wie oft
• Wo die Protokolle liegen und wie lange sie erhalten bleiben
• Wer die Zugänge verwaltet und wann sie ablaufen

Was Sie jetzt tun können

1. Schreiben Sie den Zettel für jeden laufenden Ablauf, auch wenn er klein ist.
2. Fragen Sie nach, ob für jeden Ablauf eine Fehlermeldung eingerichtet ist und wohin sie geht. Prüfen Sie sie mit einem automatisch laufenden Testablauf, der absichtlich scheitert.
3. Legen Sie eine Zählprobe fest (Zeitersparnis messen statt versprechen) und tragen Sie die erste Prüfung in zwei Wochen in den Kalender ein.
4. Fragen Sie Ihren Dienstleister, wo Fehler abgefangen werden und wer dann informiert wird.