> ## Documentation Index
> Fetch the complete documentation index at: https://docs.localmind.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Retry Logic

> Retry-Mechanismen für robuste Automate-Workflows: Retry On Fail, Error-Workflows und selbstgebaute Retry-Loops.

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

<Note>
  **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](#fortgeschritten-retry-loop-im-workflow-selbstgebaut).
</Note>

## 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.

<Warning>
  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.
</Warning>

<Steps>
  <Step title="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.
  </Step>

  <Step title="Fehlerdaten auswerten">
    Der Error Trigger liefert Informationen über die fehlgeschlagene Ausführung:

    ```javascript Error-Daten im Fehlerbehandlungs-Workflow theme={null}
    // Execution-Informationen
    {{ $json.execution.id }}
    {{ $json.execution.url }}
    {{ $json.execution.lastNodeExecuted }}

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

    // Workflow-Informationen
    {{ $json.workflow.id }}
    {{ $json.workflow.name }}
    ```
  </Step>

  <Step title="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](/administration/api). Stellen Sie vor einem Neustart sicher, dass keine Duplikate entstehen — etwa indem Sie prüfen, welche Schritte bereits erfolgreich gelaufen sind.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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)
```

<Steps>
  <Step title="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.
  </Step>

  <Step title="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:

    ```javascript IF-Bedingung (max. 4 Retries) theme={null}
    {{ $runIndex < 4 }}
    ```
  </Step>

  <Step title="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).
  </Step>

  <Step title="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.
  </Step>
</Steps>

### 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:

```javascript Wait Amount (Sekunden) theme={null}
{{ 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):

```javascript Wait Amount (Sekunden) theme={null}
{{ ($runIndex + 1) * 5 }}
```

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

```javascript Exponential Backoff mit ±25% Jitter (Sekunden) theme={null}
{{ 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:

```javascript IF-Bedingung: nur bei Rate Limit retryen theme={null}
{{ $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:

```javascript Wait Amount aus Retry-After-Header (Sekunden) theme={null}
{{ 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:

```javascript Fehlversuche über Executions zählen (Code-Node) theme={null}
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](/administration/api).

## Praktisches Beispiel: API-Call absichern

1. **Retry On Fail aktivieren:** HTTP-Request-Node → **Settings** → **Retry On Fail** einschalten, **Max Tries** auf 3, **Wait Between Tries** auf 2000 ms.
2. **Error-Workflow anlegen:** Fehlerbehandlungs-Workflow mit **Error Trigger** → Benachrichtigung (z. B. E-Mail an das Team) → Logging-Schritt.
3. **Error-Workflow zuweisen:** in den **Workflow-Einstellungen** des Produktiv-Workflows unter **Error Workflow**.
4. **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.
5. **Ergebnis prüfen:** in der Executions-Liste kontrollieren, ob fehlgeschlagene Ausführungen zurückgehen und der Error-Workflow bei echten Fehlern anspringt.

## Checkliste

<Check>
  * [ ] 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
</Check>

## Nächste Schritte

<CardGroup cols={2}>
  <Card title="Automate-API" icon="code" href="/administration/api">
    Workflows über die Web-App verwalten und programmatisch mit Localmind verbinden.
  </Card>

  <Card title="Debugging" icon="bug" href="/automate/debugging">
    Erfahren Sie mehr über umfassendes Error Handling und Fehlersuche.
  </Card>

  <Card title="Batching" icon="layers" href="/automate/batching">
    Kombinieren Sie Retry-Logik mit Batch-Verarbeitung.
  </Card>

  <Card title="Performance" icon="gauge" href="/automate/performance">
    Optimieren Sie Ihre Workflows für schnellere Ausführung.
  </Card>
</CardGroup>