What is a dead-letter queue for webhooks?

It is where a delivery goes after it has exhausted its retries. Instead of being lost, the payload is held so you can inspect it and replay it once the target is healthy again.

How many times will a webhook be retried?

If your target returns a temporary error or can’t be reached, the delivery is retried with increasing backoff over a retry budget; if it still isn’t accepted, it’s held for you to replay in the dead-letter queue. Your dashboard shows each delivery’s attempts.

Are retried webhooks deduplicated?

An idempotency key deduplicates on the way in: send the same request twice and it is accepted once. Outbound delivery is at-least-once, so a retry can still reach a target that already received it — design the target to tolerate a repeat, keyed on an id you carry in the payload.

Retries & dead-letter queue

Webhook retries and a dead-letter queue, handled.

A target goes down and a dropped webhook costs you a transaction. EchoRelay retries automatically and holds what still fails in a queue you can replay — so you stop running that logic yourself.

Worked example

Recover an appointment reminder after your service fails

Your booking app confirms an appointment while your reminder service is unavailable. This example uses a fictional API and an asynchronous target with retries enabled for HTTP 503 responses.

The accepted event

{
  "eventId": "evt_73",
  "type": "appointment.confirmed",
  "appointmentId": "APPT-9"
}

Publish an endpoint with your reminder service as an asynchronous target and send the appointment event.
Your reminder service responds with HTTP 503. EchoRelay schedules another attempt using your target's retry policy.
If the configured attempts are exhausted, the delivery is held for retry in the dead-letter queue.
Restore the reminder service, inspect the failed delivery, and replay it manually.
Your receiver uses evt_73 to recognise a repeated event before sending a reminder.

Choose the retryable response codes, attempt budget, and backoff for your target before publishing. A network failure can happen after a receiver has processed the event, so a retry can deliver it again. Check that the appointment still needs a reminder before replaying it.

This retry workflow applies to asynchronous delivery. Synchronous and streaming targets have no automatic retries.

Why EchoRelay

Less to build, less to run.

Automatic retries with backoff

Transient failures are retried, spaced further apart each time — no thundering herd when a target recovers.

A dead-letter queue you can replay

What can’t be delivered after the retry budget lands in a per-project DLQ. Inspect the payload, fix the target, and replay when you’re ready.

At-least-once, with an idempotency key

Send an idempotency key and a repeated submission is accepted once, not twice. Every failure stays visible in your dead-letter queue.

Questions

Answered, honestly.

What is a dead-letter queue for webhooks?: It is where a delivery goes after it has exhausted its retries. Instead of being lost, the payload is held so you can inspect it and replay it once the target is healthy again.
How many times will a webhook be retried?: If your target returns a temporary error or can’t be reached, the delivery is retried with increasing backoff over a retry budget; if it still isn’t accepted, it’s held for you to replay in the dead-letter queue. Your dashboard shows each delivery’s attempts.
Are retried webhooks deduplicated?: An idempotency key deduplicates on the way in: send the same request twice and it is accepted once. Outbound delivery is at-least-once, so a retry can still reach a target that already received it — design the target to tolerate a repeat, keyed on an id you carry in the payload.

Connect everything. Deploy nothing.

Start free See fan-out

No credit card required.