# Wiederholungen und Fehlschläge

> Wie Emailit fehlgeschlagene Webhook-Anfragen wiederholt, wann es Ihnen eine E-Mail sendet und einen Endpunkt deaktiviert und wie Sie fehlgeschlagene Anfragen prüfen und erneut senden.

Wenn Ihr Endpunkt eine Webhook-Anfrage nicht annimmt, behält Emailit die Events und versucht es nach einem Zeitplan erneut, der etwas über drei Tage dauert. Diese Seite listet diesen Zeitplan auf, erklärt die E-Mails, die Emailit sendet, und wann es einen Endpunkt deaktiviert, und zeigt, wie Sie fehlgeschlagene Anfragen prüfen und erneut senden.

## Was als Fehlschlag gilt

Eine Anfrage schlägt fehl, wenn Ihr Endpunkt:

- einen Status außerhalb von `200`–`299` zurückgibt, auch Redirects (`3xx`).
- nicht innerhalb von 30 Sekunden antwortet.
- nicht erreichbar ist: DNS-Fehler, abgelehnte Verbindungen, TLS-Fehler oder eine URL, die zu einer privaten IP-Adresse auflöst.

Ein Fehlschlag gilt für den ganzen Batch: Alle Events der Anfrage werden gemeinsam wiederholt.

## Wiederholungsplan

Nach jedem fehlgeschlagenen Versuch wartet Emailit, bevor es einen neuen Versuch unternimmt:

| Versuch | Wartezeit nach dem vorherigen Versuch | Zeit seit dem ersten Versuch |
| --- | --- | --- |
| 1 | Innerhalb von Sekunden nach dem Event gesendet | 0 |
| 2 | 5 Minuten | 5 Minuten |
| 3 | 30 Minuten | 35 Minuten |
| 4 | 2 Stunden | 2 Stunden 35 Minuten |
| 5 | 5 Stunden | 7 Stunden 35 Minuten |
| 6 | 12 Stunden | 19 Stunden 35 Minuten |
| 7 | 12 Stunden | 1 Tag 7 Stunden |
| 8 | 12 Stunden | 1 Tag 19 Stunden |
| 9 | 12 Stunden | 2 Tage 7 Stunden |
| 10 | 12 Stunden | 2 Tage 19 Stunden |
| 11 | 12 Stunden | 3 Tage 7 Stunden |

Schlägt Versuch 11 fehl, wird die Anfrage als **Failed** markiert und nicht mehr automatisch wiederholt. Sie können sie noch 7 Tage lang [erneut senden](#resend-failed-requests).

Jeder Versuch wird mit einem neuen Zeitstempel erneut signiert. Events, die eintreffen, während frühere Anfragen auf eine Wiederholung warten, werden in eigenen Batches gesendet, sodass ein fehlerhaftes Event keine neueren blockiert.

## Benachrichtigungs-E-Mails

Emailit sendet dem Workspace-Inhaber zu zwei Zeitpunkten eine E-Mail:

| Wann | E-Mail |
| --- | --- |
| Eine Anfrage schlägt zum dritten Mal fehl (etwa 35 Minuten nach dem ersten Fehlschlag) | Der Webhook schlägt fehl. Wird einmal pro Vorfall gesendet. Eine weitere erhalten Sie erst nach einer erfolgreichen Zustellung mit anschließenden neuen Fehlschlägen oder nach 4 Tagen. |
| Der Webhook wird automatisch deaktiviert | Der Webhook wurde deaktiviert, mit dem letzten Statuscode. |

## Automatische Deaktivierung

Hatte ein Webhook seit seiner ältesten fehlschlagenden Anfrage 3 Tage lang keine erfolgreiche Zustellung, deaktiviert Emailit ihn beim nächsten fehlgeschlagenen Versuch. In der Praxis geschieht das um den 11. Versuch der ersten fehlschlagenden Anfrage herum oder früher, wenn neue Events weiter fehlschlagen.

Solange ein Webhook deaktiviert ist:

- Neue Events werden nicht für ihn in die Warteschlange gestellt. Sie werden weiterhin im [Event-Stream](/de/docs/logs/events/) aufgezeichnet.
- Anfragen, die auf eine Wiederholung warteten, bleiben ausstehend und werden fortgesetzt, sobald Sie ihn aktivieren.
- Die Webhook-Seite zeigt den Status **Disabled**.

Um ihn wieder einzuschalten, wählen Sie im Aktionsmenü des Webhooks **Enable webhook** oder rufen Sie [Webhook aktualisieren](/de/docs/api-reference/webhooks/update/) mit `{"enabled": true}` auf. **Retry failed** und das Wiederholen einer einzelnen Anfrage aktivieren den Webhook ebenfalls.

## Der Tab Requests

Öffnen Sie einen Webhook unter **Email API → Webhooks**, um seinen Tab **Requests** zu sehen, die neuesten zuerst:

| Spalte | Beschreibung |
| --- | --- |
| **Event type** | Das Event in der Anfrage. |
| **Event ID** | Die `evt_`-ID, derselbe Wert, den Ihr Endpunkt als `event_id` erhält. |
| **Created** | Zeitpunkt, zu dem die Anfrage in die Warteschlange gestellt wurde. |
| **Attempts** | Wie viele Zustellversuche bisher fehlgeschlagen sind. |
| **Status** | **Pending** (noch nicht versucht), **Attempting** (mindestens einmal fehlgeschlagen, wird wiederholt), **Delivered** oder **Failed** (Wiederholungen ausgeschöpft). |

Filtern Sie nach **Status code**, **Event** oder **Created**. Test-Events aus **Send test** werden hier nicht aufgeführt.

Wählen Sie bei einer Anfrage mit dem Status **Failed** die Option **View**, um **Failure reason** zu öffnen: den Statuscode, den Ihr Endpunkt zurückgegeben hat (`0`, wenn es keine HTTP-Antwort gab), wann die Anfrage erstellt wurde und wann sie fehlschlug, sowie die ersten 2.000 Zeichen des Antwort-Bodys.

## Fehlgeschlagene Anfragen erneut senden

Sie können Anfragen mit dem Status **Failed** erneut senden, deren letzter Fehlschlag in den vergangenen 7 Tagen lag. Erneut gesendete Anfragen wechseln zurück zu **Pending** und beginnen einen neuen Wiederholungszyklus ab Versuch 1. Die Zustellung erfolgt nicht sofort: Der nächste Zustelllauf greift sie innerhalb von Sekunden auf.

### Einzelne Anfrage wiederholen

Wählen Sie im Tab **Requests** in einer fehlgeschlagenen Zeile **Retry**. Die Schaltfläche erscheint nur bei fehlgeschlagenen Anfragen der letzten 7 Tage.

Der API-Endpunkt ist [Einzelne Anfrage wiederholen](/de/docs/api-reference/webhooks/retry-request/), `POST /v2/webhooks/{id}/requests/{request_id}/retry`, der `{"retried": 1, "id": "whr_…"}` zurückgibt. Er akzeptiert nur Anfragen mit dem Status **Failed** und gibt bei anderen `400` zurück. Anfrage-IDs (`whr_…`) werden von keinem öffentlichen Endpunkt aufgelistet; für die Automatisierung per API verwenden Sie daher stattdessen **Retry failed**.

### Fehlgeschlagene Anfragen wiederholen

Öffnen Sie das Aktionsmenü des Webhooks und wählen Sie **Retry failed**. Jede Anfrage, die in den letzten 7 Tagen fehlgeschlagen ist, wird erneut in die Warteschlange gestellt, und die Weboberfläche zeigt „Queued 3 failed request(s) for retry“ mit der tatsächlichen Anzahl oder „No failed requests in the last 7 days“.

Rufen Sie per API [Fehlgeschlagene Anfragen wiederholen](/de/docs/api-reference/webhooks/retry-failed/) auf:

```bash
curl -X POST https://api.emailit.com/v2/webhooks/wh_2xGk8Hd3RvN6qT1mWsB9cL4pZ7e/retry-failed \
  -H "Authorization: Bearer $EMAILIT_API_KEY"
```

```json
{ "retried": 42 }
```

## Nach einem Ausfall wiederherstellen

1. **Endpunkt reparieren.** Sehen Sie mit **View** bei einer fehlgeschlagenen Anfrage nach, was Ihr Endpunkt zurückgegeben hat.

2. **Funktion bestätigen.** Verwenden Sie **Send test** im Aktionsmenü oder per API [Test-Event senden](/de/docs/api-reference/webhooks/test/) und prüfen Sie, ob ein `2xx` zurückkommt.

3. **Webhook aktivieren**, falls Emailit ihn deaktiviert hat.

4. **Fehlschläge erneut senden.** Wählen Sie **Retry failed**, um jede Anfrage, die in den letzten 7 Tagen fehlgeschlagen ist, erneut in die Warteschlange zu stellen. Anfragen, die noch als **Attempting** markiert sind, werden nach ihrem eigenen Zeitplan wiederholt.

5. **Lücken auffüllen.** Events, die eintraten, während der Webhook deaktiviert war, wurden nie in die Warteschlange gestellt, und Fehlschläge, die älter als 7 Tage sind, lassen sich nicht erneut senden. Lesen Sie sie für den betroffenen Zeitraum mit der [Events-API](/de/docs/logs/events/#reconcile-missed-webhook-events) und verarbeiten Sie die fehlenden.

Da Wiederholungen ganze Batches erneut senden, sollten Sie Ihren Handler idempotent gestalten: Speichern Sie jede `event_id` und überspringen Sie bereits verarbeitete. Siehe [Webhook-Anfragen](/de/docs/webhooks/webhook-requests/#duplicates).

## Aufbewahrung

Webhook-Anfragen folgen der Aufbewahrungsdauer für **Logs**, daher verschwinden ältere Zeilen mit der Zeit aus dem Tab **Requests**.

| | Pay as you go | Pro | Business | Custom |
| --- | --- | --- | --- | --- |
| Aufbewahrung der Anfrage-Logs | 7 Tage | 30 Tage | 30 Tage | Flexibel |

## Siehe auch

  - [Webhook-Anfragen](/de/docs/webhooks/webhook-requests/)
  - [Events](/de/docs/logs/events/)

---
Quelle: https://emailit.com/de/docs/webhooks/retries-and-failures/