The DLQ view at Projects → your project → DLQ lists every endpoint delivery that terminally failed — i.e. exhausted the endpoint’s retry policy without ever receiving a 2xx response. Each row is one (event × endpoint) pair, so an event that failed on two endpoints appears twice.
For the full retry model, see Retries & dead-letter.
What a row tells you
- The originating event — source pill, summary, timestamp. Click through for the full payload.
- The endpoint URL that failed.
- The last HTTP status code (or the error if the connection never completed — DNS, TLS, timeout).
- The error message returned on the final attempt.
- Attempts — how many tries were made before giving up.
Rows are sorted newest-first. Filter by endpoint, time window, or search against the event summary to narrow down.
Replaying from DLQ
Two shortcuts are on every row:
- replay — re-dispatches the event through the current fanout. Handy when the upstream service has recovered and you just want another go.
- open event — pivots to the full event detail, where you can use edit-and-replay to tweak the webhook body first.
A successful replay walks the event’s overall status from failed back to
delivered and the row remains visible in the DLQ for audit. That way a
manually-recovered delivery still shows up in the historical record, just
with the replay attempt attached.
Retention
DLQ rows age out with their parent event — the window matches your plan’s replay retention:
| Tier | DLQ retention |
|---|---|
| Hobby | 7 days |
| Hacker | 14 days |
| Pro | 30 days |
| Scale | 90 days |
If your plan changed recently, retention also honours a short grace window on the previous plan’s retention — see Billing.