Dead Letter Queue

The DLQ is where you review Deliveries that can no longer make automatic progress.

How a Delivery enters the DLQ

A Delivery becomes dead_letter when:

• all configured attempts are exhausted;
• the 24-hour retry window is reached;
• a terminal Destination response (4xx other than the retryable set, 3xx) occurs;
• policy blocks the Destination, the TLS certificate is invalid, or the payload expires;
• the Destination signing secret is unavailable.

The original Event, retained payload, and attempt history remain available subject to retention.

What the DLQ shows

Each row shows:

• the ticket-like Delivery and Event references;
• the upstream Event ID when present;
• the Destination name and URL;
• total attempts and attempts in the current replay cycle;
• the last error;
• when the Delivery was created.

Open a row to inspect recent attempts and, when capture was enabled, bounded response snippets.

What the DLQ does not do

• It does not automatically retry forever.
• It does not guarantee that a replay will succeed.
• It does not restore an expired payload.
• It does not bypass Destination policy or archive state.
• It does not merge duplicate Events; deduplication happens at ingestion.

Inspect before replaying

Check:

1. the last HTTP status and error;
2. the captured response snippet, if present;
3. the Destination URL and whether it is archived or disabled;
4. the Source's signing configuration;
5. whether the payload is still retained.

Fix the Destination first. Then replay with a clear reason.