Dead-letter queue

Inspect and replay endpoint deliveries that exhausted their retry policy.

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:

TierDLQ retention
Hobby7 days
Hacker14 days
Pro30 days
Scale90 days

If your plan changed recently, retention also honours a short grace window on the previous plan’s retention — see Billing.