# 08 — Fehlerbehandlung

> Ein Workflow der still scheitert ist schlimmer als einer der laut scheitert.
> Stille Fehler laufen Wochen unbemerkt weiter.

---

## Das Standardverhalten

Wenn ein Node einen Fehler wirft (API-Timeout, ungültige Daten, Netzwerkfehler), stoppt n8n die Execution standardmäßig. Die restlichen Nodes werden nicht ausgeführt.

Das ist besser als nichts. Aber es ist nicht gut genug für produktive Workflows.

---

## Ebene 1: Node-Level Error Output

Jeder Node in n8n hat einen unsichtbaren zweiten Output: den Error Output.  
Du aktivierst ihn im Node-Menü unter "Add Error Output".

Wenn der Node nun fehlschlägt:
- Normale Execution stoppt an diesem Node
- Die Fehler-Items fließen in den Error Output weiter
- Der Rest des Workflows kann auf beiden Pfaden weiterlaufen

```
[HTTP Request]
    ├─ success → [Verarbeitung]
    └─ error   → [Error-Handling: Log, Notify, Retry]
```

Das gibt dir pro Node die Kontrolle: Was passiert wenn dieser spezifische Schritt scheitert?

### Verfügbare Felder im Error Output
```js
$json.error.message      // Fehlermeldung
$json.error.name         // Fehlertyp (z.B. "NodeApiError")
$json.error.httpCode     // HTTP-Status wenn API-Fehler
$json.error.description  // Detailliertere Beschreibung
```

---

## Ebene 2: Error Workflows

Ein Error Workflow ist ein separater Workflow, der automatisch ausgelöst wird wenn ein anderer Workflow fehlschlägt.

Konfiguration: In Workflow-Einstellungen → "Error Workflow" → deinen Error-Handler-Workflow auswählen.

Der Error Workflow bekommt Kontextdaten über den Fehler:
```js
$json.workflow.id
$json.workflow.name
$json.execution.id
$json.execution.url        // Link zur fehlgeschlagenen Execution
$json.error.message
$json.error.node.name      // Welcher Node scheiterte
```

Typisches Error-Workflow-Muster:
```
[Error Trigger]
    ↓
[Set: Fehlernachricht formatieren]
    ↓
[Send Email / Slack / Telegram: "Workflow X scheiterte bei Node Y"]
```

Das ist Pflicht für produktive Workflows. Sonst bemerkst du Probleme erst wenn User sich beschweren.

---

## Retry-Logik

Im HTTP Request Node gibt es eingebaute Retry-Konfiguration:
- **Anzahl Retries:** Wie oft erneut versuchen
- **Retry-Intervall:** Wie lange warten zwischen Versuchen

Für transiente Fehler (Netzwerkfluktuationen, temporäre API-Überlastung) löst Retry die meisten Probleme ohne Intervention.

Für dauerhafte Fehler (falscher API-Key, ungültige Daten) hilft Retry nicht — das muss in den Error Output.

---

## Graceful Degradation: Continue on Error

Manchmal willst du dass ein Workflow weiterlaufen soll, auch wenn ein Node scheitert — und den Fehler dabei festhalten.

Im Node-Menü: "Settings" → "On Error" → "Continue (using Error Output)"

Der Node gibt ein Error-Item in seinen normalen Output. Dein Workflow kann danach prüfen:
```js
{{ $json.error !== undefined }}    // Ist dieses Item ein Fehler?
```

Und entsprechend reagieren — ohne den ganzen Workflow zu unterbrechen.

---

## Häufige Fehlertypen und ihre Bedeutung

| Fehlertyp | Bedeutung | Typische Lösung |
|-----------|-----------|-----------------|
| `NodeApiError` | HTTP-Fehler von einer API | Status-Code prüfen, Auth validieren |
| `401 Unauthorized` | Credential ungültig oder abgelaufen | OAuth Token erneuern |
| `429 Too Many Requests` | Rate-Limit erreicht | SplitInBatches + Wait |
| `NodeOperationError` | Falsche Node-Konfiguration | Felder und Expressions prüfen |
| `ECONNREFUSED` | Ziel nicht erreichbar | Netzwerk prüfen, URL validieren |
| `Unexpected token` | Ungültiges JSON in Response | Response-Body vor Parsing prüfen |

---

## Anti-Pattern: Kein Error-Handling

```
[Webhook] → [HTTP Request] → [DB Write] → [Response]
```

Was passiert wenn HTTP Request scheitert? Workflow stoppt. DB Write passiert nicht. Response kommt nie an. User wartet.

Was passiert wenn DB Write scheitert? Workflow stoppt. Response kommt nie an.

Was passiert eine Woche später? Niemand weiß wie viele Requests fehlgeschlagen sind.

Besser:
```
[Webhook] → [HTTP Request]
                ├─ success → [DB Write] → [200 Response]
                │                └─ error → [500 Response + Log]
                └─ error → [500 Response + Alert]
```

---

## Zusammenfassung

| Methode | Wann nutzen |
|---------|-------------|
| Error Output am Node | Reaktion auf spezifischen Node-Fehler |
| Error Workflow | Globales Monitoring, Alerting bei jedem Workflow-Fehler |
| Retry-Konfiguration | Transiente Fehler, flakige APIs |
| Continue on Error | Workflow soll trotz Fehler weiterlaufen |

---

**Nächste Seite:** [09 — Credentials & Auth](09-credentials-auth.md)