Retries & Dead Letter

How Hookdrop automatically retries failed deliveries and what happens when all attempts are exhausted.

When Hookdrop cannot deliver an event to a destination — because your server is down, times out, or returns a non-2xx response — it retries automatically. You do not need to configure anything.

Retry schedule

Hookdrop uses exponential backoff, spacing retries further apart with each failure:

Attempt	Delay after previous failure
1	Immediate
2	5 seconds
3	30 seconds
4	2 minutes
5	10 minutes

The first attempt happens immediately when the event is received. The schedule above applies to each subsequent retry after a failure.

Dead letter queue

After 4 failed retry attempts (5 total attempts including the first), Hookdrop moves the event to the dead letter queue and stops retrying.

When this happens:

1. You receive an email alert with a link to the affected event.
2. The event stays in the queue — it is not discarded and its full payload is preserved.
3. You replay it manually once your server is back up and accepting requests.

Check your email alerts promptly. Events remain in the dead letter queue indefinitely, but the longer you wait to replay them, the further out of order they may arrive relative to newer events.

Replay a dead-letter event

Dashboard

1. Find the event

   Open the endpoint in the dashboard and filter the event list by Status: dead_letter.

2. Open the event

   Click the event to open its detail view.

3. Replay

   Click Replay event. Hookdrop re-enqueues the event and attempts delivery to all configured destinations immediately.

API

Send a POST request to the replay endpoint:

POST /api/endpoints/:id/events/:eventId/replay
Authorization: Bearer TOKEN

Hookdrop re-enqueues the event and begins delivery attempts immediately. A successful response confirms the event has been queued — it does not mean delivery has completed yet.

Before replaying, open the Deliveries tab on the event and review the response codes and response bodies from your server. This tells you exactly why the original delivery failed, so you can verify the issue is resolved before triggering another attempt.

Related

• Destinations — configure where events are forwarded and set delivery timeouts
• Events API reference — replay events and retrieve delivery logs programmatically