Replay an email-triggered event after your consumer was down

The question every evaluator eventually asks about a non-HTTP channel is: what happens when my side is down?

For most inbound email services the answer is a bounded retry window — Mailgun backs off across roughly eight hours, Postmark makes ten attempts over about ten and a half, SendGrid keeps going for seventy-two. After that the message is gone, and in SendGrid's case the sender gets no bounce and there is no dashboard alert, so you find out from your own logs or not at all.

This guide covers what recovery looks like when the email is a delivery in a pipeline instead.

The stages

An email-sourced delivery goes through exactly the same stages as an HTTP one:

1. Accepted. The message is parsed and the source payload persisted before anything is attempted.
2. Attempted. Delivery to the resolved destination, with each attempt recorded.
3. Retried. Failures retry under the webhook's retry policy with exponential backoff.
4. Dead-lettered. When retries are exhausted the delivery moves to the DLQ rather than being dropped.

The important difference from a bounded retry window is stage 4. Nothing expires into nothing.

Find the message

Delivery history is filterable by channel, so you can isolate email traffic during the outage window rather than scrolling through everything. History retention depends on plan — seven days with three-day payload retention on Free, longer on paid tiers — which is worth checking against how long an outage might realistically go unnoticed.

Replay it

A single delivery can be replayed from the dashboard or the API. Bulk re-drive of the dead-letter path — the thing you actually want after an outage — requires Starter or above.

The property that matters here is deterministic replay. A replay reuses the persisted dispatch snapshot: the payload as it arrived, and the destination, transform, and routing configuration as they were resolved at the time. It does not re-evaluate today's routing table against a month-old message.

Replays and the stored payload

Replays reuse the same stored payload as the source delivery rather than duplicating it, and that shared object is retained based on the newest reference to it — not on the status of the original delivery. A replayed message keeps its payload alive.

Attachments

Attachment files persist with the delivery on paid plans, so a replayed email still carries fetchable fileRef URLs. On the free plan attachments are metadata-only at ingest, so a replay reproduces the metadata but there is no file to fetch. If attachments are load-bearing for recovery, that is a reason to be on a paid tier.

What to check before you rely on this

• Retry policy. Custom retry configuration requires Starter or above; Free uses the default.
• Bulk re-drive. Starter and above. On Free you can replay deliveries individually but not re-drive the dead-letter path in bulk.
• Alerts. Alerting on failures is a Pro feature. Without it, discovering the outage is still on you — the difference is that the messages are still there when you do.
• Retention. Confirm history and payload retention on your plan covers your realistic detection time.

Where to go next

• Email to webhook for the channel overview
• Inbound email services compared for how the dedicated services handle failure
• Recover failed agent events with DLQ and replay for the general recovery path
• Webhook DLQs: design and recovery patterns