# Warum hängt meine E-Mail in Accepted oder Scheduled fest?

> Angenommene E-Mails gehen normalerweise innerhalb von Sekunden hinaus, geplante zu ihrem Sendezeitpunkt. Finden Sie heraus, was sie verzögert und wann Sie stornieren, verschieben oder erneut senden sollten.

Dieser Artikel hilft, wenn eine E-Mail länger als erwartet in **Accepted** oder **Scheduled** bleibt. Beide Status bedeuten, dass Emailit die E-Mail hat und noch keinen Zustellversuch abgeschlossen hat.

## Symptome

- Eine E-Mail zeigt viele Minuten lang **Accepted** („Accepted for delivery“).
- Eine geplante E-Mail zeigt noch **Scheduled**, obwohl der erwartete Sendezeitpunkt vorbei ist.
- Der Tab **Deliveries** auf der Seite der E-Mail ist leer oder zeigt einen Eintrag zu einem internen Fehler.

## Ursache

E-Mails mit **Accepted** stehen in der Warteschlange und werden normalerweise innerhalb von Sekunden gesendet. Länger bleiben sie, wenn:

- **ein Zustellversuch auf einen internen Fehler gestoßen ist.** Der Tab **Deliveries** zeigt `An internal error occurred while sending this email. This message will be retried automatically.` Die E-Mail behält ihren Status und wird mit wachsenden Abständen erneut versucht.
- **Emailit einen Rückstau oder einen Vorfall abarbeitet.** Prüfen Sie [status.emailit.com](https://status.emailit.com).

Beachten Sie, dass eine vorübergehende Ablehnung durch den Server des Empfängers als **Attempted** erscheint, nicht als **Accepted**. Siehe [Was bedeutet der Status Attempted?](/de/docs/kb/email-status-attempted/).

E-Mails mit **Scheduled** warten bis zu ihrem Zeitpunkt `scheduled_at` und gehen dann innerhalb von Sekunden hinaus. Sie wechseln direkt von **Scheduled** zu **Delivered** oder einem anderen endgültigen Status, ohne **Accepted** zu durchlaufen. Eine geplante E-Mail, die verspätet scheint, ist meist:

- **für eine andere Zeit geplant als beabsichtigt.** Eine Zeitangabe ohne Offset oder eine Formulierung wie „tomorrow at 9am“ kann in einer anderen Zeitzone als Ihrer interpretiert werden.
- **durch dieselben internen Fehler wie oben verzögert.**

## Lösung

1. **Zeitangaben der E-Mail prüfen.** Öffnen Sie sie unter **Email API → Emails**. Die Übersicht zeigt, wann sie erstellt wurde und, bei geplanten E-Mails, für wann sie geplant ist. Wechseln Sie zum Vergleich im Nutzermenü unter **Timezone** zwischen UTC und Ortszeit.

2. **Tab Deliveries lesen.** Zeigt er einen internen Fehler, versucht Emailit es selbstständig erneut. Sie müssen nicht erneut senden, ein erneutes Senden erzeugt ein Duplikat.

3. **Explizite Zeitzonen verwenden.** Senden Sie `scheduled_at` im Format ISO 8601 mit Offset, etwa `2026-10-02T09:00:00+02:00`, oder als Unix-Zeitstempel. Die API-Antwort gibt den geparsten Wert `scheduled_at` zurück. Protokollieren Sie ihn also und vergleichen Sie. Siehe [Planung](/de/docs/email-api/scheduling/).

4. **Bei Bedarf verschieben oder stornieren.** Rufen Sie [Geplante E-Mail aktualisieren](/de/docs/api-reference/emails/update/) mit einem neuen `scheduled_at` auf oder wählen Sie **Cancel delivery** auf der Seite der E-Mail. Beides funktioniert nur bis 3 Minuten vor dem geplanten Zeitpunkt, und der neue Zeitpunkt muss mindestens 3 Minuten in der Zukunft liegen.

5. **Auf einen Vorfall prüfen.** Hängen viele E-Mails gleichzeitig fest, prüfen Sie [status.emailit.com](https://status.emailit.com), bevor Sie etwas erneut senden.

Um E-Mails in Echtzeit zu verfolgen, abonnieren Sie mit einem [Webhook](/de/docs/webhooks/) die Events `email.delivered`, `email.attempted` und `email.bounced`. Alle Status finden Sie unter [E-Mail-Status](/de/docs/logs/email-statuses/).

## Weiterhin Probleme?

Wenn eine E-Mail länger als eine Stunde **Accepted** bleibt und kein Vorfall gemeldet ist, [kontaktieren Sie den Support](/contact/) oder fragen Sie auf [Discord](https://discord.emailit.com) und nennen Sie die E-Mail-ID (`em_…`).

---
Quelle: https://emailit.com/de/docs/kb/email-stuck-in-scheduled-or-accepted/