Retry Logic

Retry-Logik wiederholt fehlgeschlagene Operationen automatisch. Temporäre Fehler — Netzwerk-Timeouts, API-Rate-Limits (429), Server-Überlastung (503), kurze Verbindungsprobleme — sind häufig; ohne Retry bedeutet jeder davon eine fehlgeschlagene Execution mit manueller Intervention und möglichem Datenverlust. Mit Retry werden temporäre Fehler überwunden, die Erfolgsrate steigt.

Drei Mechanismen im Überblick

Mechanismus	Wo konfiguriert	Geeignet für
Retry On Fail (eingebaut)	Node-Einstellungen	Standardfall: temporäre Fehler einzelner Nodes automatisch wiederholen
Error-Workflow	Workflow-Einstellungen → Error Workflow	Zentrale Fehlerbehandlung: Benachrichtigung, Logging, ggf. Neustart über die Automate-API
Retry-Loop (selbstgebaut)	IF-Node + Wait-Node + Rückverbindung	Exponential Backoff, selektive Retries nach Fehlertyp

Beginnen Sie immer mit Retry On Fail — es deckt die meisten Fälle ohne zusätzliche Nodes ab. Die anderen beiden Patterns sind Ergänzungen, kein Ersatz.

Retry On Fail: das eingebaute Node-Setting

Jeder Node bringt eine eingebaute Retry-Funktion mit. Öffnen Sie den Node (z. B. einen HTTP-Request-Node), wechseln Sie vom Parameter-Tab in den Settings-Tab und schalten Sie Retry On Fail ein. Zwei Parameter steuern das Verhalten:

Max Tries — wie oft der Node insgesamt versucht wird (Standard: 3)
Wait Between Tries — Wartezeit zwischen den Versuchen in Millisekunden (Standard: 1000 ms); bei Rate-Limit-Fehlern lohnt sich ein höherer Wert

Grenzen von Retry On Fail: Die Wartezeit ist konstant (kein Exponential Backoff), und der Node wiederholt bei jedem Fehler — er unterscheidet nicht zwischen retryable (429, 503) und non-retryable Fehlern (400, 401). Wenn Sie das brauchen, nutzen Sie den selbstgebauten Retry-Loop.

Retryable vs. Non-Retryable Fehler

Nicht jeder Fehler sollte wiederholt werden — als Faustregel sind 5xx-Fehler oft retryable, 4xx-Fehler meist nicht:

Fehler	Retry?	Grund
429 Too Many Requests	Ja	Rate Limit erreicht — Wartezeit hilft
503 Service Unavailable	Ja	Temporäre Server-Überlastung
504 Gateway Timeout	Ja	Timeout — möglicherweise temporär
ECONNRESET	Ja	Verbindung zurückgesetzt — Netzwerkproblem
ETIMEDOUT	Ja	Timeout — möglicherweise temporär
500 Internal Server Error	Manchmal	Temporär oder dauerhaft — abhängig von der API
400 Bad Request	Nein	Ungültige Anfrage — wird nicht besser
401 Unauthorized	Nein	Authentifizierung fehlgeschlagen
403 Forbidden	Nein	Keine Berechtigung
404 Not Found	Nein	Ressource existiert nicht
422 Unprocessable Entity	Nein	Validierungsfehler

Error-Workflow: Fehler zentral behandeln

Der Error Trigger-Node startet einen separaten Fehlerbehandlungs-Workflow, sobald ein Produktiv-Workflow fehlschlägt. Er eignet sich für Benachrichtigungen, Logging und das gezielte Neu-Anstoßen von Workflows über die Automate-API. Beachten Sie: Error-Workflows werden nur bei Production-Executions ausgelöst (aktivierte Workflows) — nicht bei manuellen Test-Ausführungen im Editor.

Der Error Trigger ist kein In-Place-Retry: Er kann nicht in den fehlgeschlagenen Workflow „zurückschleifen” und dort weitermachen. Er startet eine eigene, unabhängige Ausführung des Fehlerbehandlungs-Workflows.

Fehlerbehandlungs-Workflow anlegen

Erstellen Sie einen neuen Workflow, dessen erster Node ein Error Trigger ist. Dieser Workflow enthält Ihre Fehlerbehandlung — zum Beispiel eine Benachrichtigung per E-Mail oder Chat und einen Logging-Schritt.

Fehlerdaten auswerten

Der Error Trigger liefert Informationen über die fehlgeschlagene Ausführung:

Error-Daten im Fehlerbehandlungs-Workflow

// Execution-Informationen
{{ $json.execution.id }}
{{ $json.execution.url }}
{{ $json.execution.lastNodeExecuted }}

// Fehlerinformationen
{{ $json.execution.error.message }}

// Workflow-Informationen
{{ $json.workflow.id }}
{{ $json.workflow.name }}

Optional: Workflow erneut anstoßen

Wenn ein erneuter Durchlauf sinnvoll ist, führen Sie den betroffenen Workflow über die Web-App erneut aus — bzw. programmatisch, siehe Automate-API. Stellen Sie vor einem Neustart sicher, dass keine Duplikate entstehen — etwa indem Sie prüfen, welche Schritte bereits erfolgreich gelaufen sind.

Error-Workflow im Produktiv-Workflow zuweisen

Öffnen Sie in Ihrem Produktiv-Workflow die Workflow-Einstellungen und wählen Sie unter Error Workflow den Fehlerbehandlungs-Workflow aus.

Fortgeschritten: Retry-Loop im Workflow (selbstgebaut)

Wenn Sie Exponential Backoff oder selektive Retries (nur bei bestimmten Fehlern) brauchen, können Sie einen Retry-Loop selbst bauen. Das ist ein DIY-Pattern — Automate bringt dafür keinen fertigen Baustein mit. Struktur des Loops:

HTTP Request (On Error: Continue using error output)
 ├─ Success-Output → Workflow läuft normal weiter
 └─ Error-Output   → IF (Versuche übrig?)
      ├─ true  → Wait (Backoff-Wartezeit) → zurück zum HTTP Request
      └─ false → Stop And Error (oder Benachrichtigung)

Fehler-Output aktivieren

Setzen Sie im Settings-Tab des Nodes die Option On Error auf Continue (using error output). Der Node bricht dann bei Fehlern nicht ab, sondern gibt die Fehlerdaten über einen zweiten Output aus.

IF-Node: Versuche zählen

Verbinden Sie den Error-Output mit einem IF-Node. Nutzen Sie $runIndex, um die Loop-Durchläufe innerhalb der Execution zu zählen — ein separater Zähler ist nicht nötig:

IF-Bedingung (max. 4 Retries)

{{ $runIndex < 4 }}

Wait-Node: Backoff-Wartezeit

Verbinden Sie den True-Output des IF-Nodes mit einem Wait-Node und hinterlegen Sie die Wartezeit als Expression (siehe Backoff-Strategien unten).

Loop schließen und Abbruchpfad definieren

Verbinden Sie den Wait-Node zurück mit dem HTTP-Request-Node. Den False-Output des IF-Nodes verbinden Sie mit einem Stop And Error-Node (oder einer Benachrichtigung), damit der Workflow nach dem letzten Versuch sauber fehlschlägt.

Backoff-Strategien für den Wait-Node

Exponential Backoff (empfohlen): Die Wartezeit verdoppelt sich mit jedem Versuch — das gibt überlasteten Servern Zeit zur Erholung. Ergibt 1 s → 2 s → 4 s → 8 s → …, gedeckelt bei 60 Sekunden:

Wait Amount (Sekunden)

{{ Math.min(Math.pow(2, $runIndex), 60) }}

Linear Backoff: Die Wartezeit wächst gleichmäßig (5 s → 10 s → 15 s → …). Eine konstante Wartezeit erreichen Sie einfacher über das eingebaute Retry On Fail (Wait Between Tries):

Wait Amount (Sekunden)

{{ ($runIndex + 1) * 5 }}

Jitter: Zufällige Variation (±10–25 %) verhindert Thundering Herd — wenn viele Executions gleichzeitig fehlschlagen, retryen sie sonst alle im selben Moment:

Exponential Backoff mit ±25% Jitter (Sekunden)

{{ Math.min(Math.pow(2, $runIndex), 60) * (0.75 + Math.random() * 0.5) }}

Selektiver Retry nach Fehlertyp

Werten Sie im IF-Node zusätzlich die Fehlerdaten aus dem Error-Output aus, um nur retryable Fehler zu wiederholen:

IF-Bedingung: nur bei Rate Limit retryen

{{ $runIndex < 4 && $json.error.message.includes('429') }}

Retry-After-Header respektieren: Bei 429-Antworten liefern viele APIs einen Retry-After-Header mit der empfohlenen Wartezeit. Konfigurieren Sie den HTTP-Request-Node über die Response-Optionen so, dass er die vollständige Response inklusive Header und Statuscode ausgibt (statt bei Fehlern abzubrechen). Prüfen Sie dann im IF-Node den Statuscode und übernehmen Sie die Wartezeit in den Wait-Node:

Wait Amount aus Retry-After-Header (Sekunden)

{{ Number($json.headers['retry-after']) || 60 }}

Zustand über Executions hinweg: Für Zustand, der mehrere Executions überdauern soll (z. B. „wie oft ist dieser Workflow heute schon fehlgeschlagen?”), bietet Automate Workflow Static Data. Zugriff im Code-Node über $getWorkflowStaticData() — beachten Sie, dass Static Data nur bei Production-Executions (aktivierter Workflow) gespeichert wird; bei manuellen Test-Ausführungen im Editor gehen Änderungen verloren:

Fehlversuche über Executions zählen (Code-Node)

const staticData = $getWorkflowStaticData('global');
staticData.failCount = (staticData.failCount || 0) + 1;

return [{ json: { failCount: staticData.failCount } }];

Best Practices

Max Retries begrenzen: typisch 3–5 Versuche — zu viele Retries erhöhen Kosten, unendliche Loops sind zu vermeiden.
Exponential Backoff mit Jitter verwenden: das Standard-Pattern — schont Server und verteilt Last gleichmäßig.
Retryable von non-retryable Fehlern unterscheiden: siehe Tabelle oben — 4xx-Fehler meist nicht wiederholen.
Timeouts ausbalancieren: zu kurze Timeouts erzeugen unnötige Retries, zu lange verzögern die Fehlerbehandlung.
Fehler protokollieren: den Error-Workflow als Logging-Punkt nutzen — Fehlermeldung und Workflow-Name in ein externes Ziel schreiben (z. B. Datenbank oder Chat-Kanal).
Retry-Strategie dokumentieren — für zukünftige Wartung.

Retry-Versuche nachvollziehen (DIY-Logging)

Automate hat kein eingebautes Retry-Metriken-Dashboard. Zum Nachvollziehen von Fehlern und Wiederholungen nutzen Sie:

Executions-Liste: zeigt Status und Dauer jeder Ausführung. Filtern Sie nach fehlgeschlagenen Executions, um Problemfälle zu finden.
Error-Workflow als Logging-Punkt: schreiben Sie Fehlermeldung, Workflow-Name und Zeitstempel in ein externes Ziel Ihrer Wahl (z. B. Datenbank, Spreadsheet oder Chat-Kanal) — ein selbstgebautes Pattern, das Sie an Ihre Umgebung anpassen.
Eigene Auswertung: wenn Sie Executions über die Web-App hinaus auswerten möchten — etwa programmatisch — siehe Automate-API.

Praktisches Beispiel: API-Call absichern

Retry On Fail aktivieren: HTTP-Request-Node → Settings → Retry On Fail einschalten, Max Tries auf 3, Wait Between Tries auf 2000 ms.
Error-Workflow anlegen: Fehlerbehandlungs-Workflow mit Error Trigger → Benachrichtigung (z. B. E-Mail an das Team) → Logging-Schritt.
Error-Workflow zuweisen: in den Workflow-Einstellungen des Produktiv-Workflows unter Error Workflow.
Bei Bedarf: Retry-Loop ergänzen: wenn die API häufig mit 429 antwortet, den selbstgebauten Retry-Loop mit Exponential Backoff bauen — Retry On Fail allein wartet nur konstant.
Ergebnis prüfen: in der Executions-Liste kontrollieren, ob fehlgeschlagene Ausführungen zurückgehen und der Error-Workflow bei echten Fehlern anspringt.

Checkliste

Retry On Fail ist für fehleranfällige Nodes aktiviert
Max Tries ist begrenzt (3-5)
Ein Error-Workflow ist angelegt und zugewiesen
Bei Bedarf: Retry-Loop mit Exponential Backoff und Jitter gebaut
Retryable/Non-Retryable Fehler werden unterschieden (im DIY-Loop)
Retry-After-Header wird respektiert
Fehler werden über den Error-Workflow protokolliert (DIY)
Executions-Liste wird regelmäßig auf Fehler geprüft

Nächste Schritte

Automate-API

Workflows über die Web-App verwalten und programmatisch mit Localmind verbinden.

Debugging

Erfahren Sie mehr über umfassendes Error Handling und Fehlersuche.

Batching

Kombinieren Sie Retry-Logik mit Batch-Verarbeitung.

Performance

Optimieren Sie Ihre Workflows für schnellere Ausführung.

Grundlagen

Localmind anbinden

Workflows

Erweitert

Betrieb

Drei Mechanismen im Überblick

Retry On Fail: das eingebaute Node-Setting

Retryable vs. Non-Retryable Fehler

Error-Workflow: Fehler zentral behandeln

Fortgeschritten: Retry-Loop im Workflow (selbstgebaut)

Backoff-Strategien für den Wait-Node

Selektiver Retry nach Fehlertyp

Best Practices

Retry-Versuche nachvollziehen (DIY-Logging)

Praktisches Beispiel: API-Call absichern

Checkliste

Nächste Schritte

Automate-API

Debugging

Batching

Performance

​Drei Mechanismen im Überblick

​Retry On Fail: das eingebaute Node-Setting

​Retryable vs. Non-Retryable Fehler

​Error-Workflow: Fehler zentral behandeln

​Fortgeschritten: Retry-Loop im Workflow (selbstgebaut)

​Backoff-Strategien für den Wait-Node

​Selektiver Retry nach Fehlertyp

​Best Practices

​Retry-Versuche nachvollziehen (DIY-Logging)

​Praktisches Beispiel: API-Call absichern

​Checkliste

​Nächste Schritte

Automate-API

Debugging

Batching

Performance

Drei Mechanismen im Überblick

Retry On Fail: das eingebaute Node-Setting

Retryable vs. Non-Retryable Fehler

Error-Workflow: Fehler zentral behandeln

Fortgeschritten: Retry-Loop im Workflow (selbstgebaut)

Backoff-Strategien für den Wait-Node

Selektiver Retry nach Fehlertyp

Best Practices

Retry-Versuche nachvollziehen (DIY-Logging)

Praktisches Beispiel: API-Call absichern

Checkliste

Nächste Schritte