Retries

A retry is a new delivery attempt for an event. Retries can be triggered manually on any event, scheduled or automatically on failed events.

Retries

Events are limited to 50 automatic retries, but can be manually retried as many times as you like.

Manually retry events

Manually retrying events allows you to re-attempt delivery to a destination.

Manual retries are useful when troubleshooting, testing, or after resolving an issue on the destination. If a manual retry is successful, any further automatic retries on that event will be canceled – otherwise, future retries will continue as planned.

Manual retries can be triggered individually or in bulk.

Retry a single event

  1. Locate the event you wish to retry and click it to select it.
  2. In the right-hand panel that appears, click Retry.
POST /events/:id/retry

Hookdeck will now attempt to deliver the event to its destination. If it succeeds, any scheduled automatic retries for that event will be canceled.

Retry many events

Bulk retrying events may impact your delivery latency, as retries are queued alongside new events.

  1. Locate a list of events you wish to retry, either by filtering your event list or opening a custom event view.
  2. Click Bulk Retry.
  3. Click Retry All.
  4. Optional: If you need to cancel a bulk retry, click Bulk Retry, click the Ongoing tab, select the retry you'd like to cancel, and click Cancel.
POST /bulk/requests/retry

Hookdeck will now attempt to deliver the events. For each event whose delivery succeeds, any scheduled automatic retries will be canceled.

Automatically retry events

With automatic retries, Hookdeck will continue to attempt delivery for failed events.

Each automatic retry is counted as a new delivery attempt. Once an attempt succeeds, further automatic retries on that event are canceled.

Events are limited to 50 automatic retries, but can still be manually retried after that limit is hit.

Configuring automatic retries

Configure a connection's automatic retries by setting its retry rule. There you can define the number of automatic retries Hookdeck will attempt after an event fails, the time interval between each attempt, the retry strategy and the response HTTP status codes to apply the retry rule to.

The retry strategy can be either linear or exponential. With a linear strategy, retries occur at regular intervals; with an exponential strategy, each retry is delayed twice as long as the previous (1 hour, 2 hours, 4 hours, etc.).

The response status codes can be used to specify which status codes should trigger a retry. For example, if you set the retry rule to apply to status codes 500-599, Hookdeck will retry events that receive any of those status codes. The status codes supports inclusion, exclusion, ranges and greater than/less than comparisons (>=, <=, >, <).

For example, to retry all 5xx errors, you can use 500-599 or >=500 and to retry all 5xx errors except 501 you can use 500-599, !501.

In the case of a conflicting HTTP status code, Hookdeck will take the last matching statement. For example, 500, !500 will not retry 500s.

Identifying retries

When a HTTP request is made to your destination, Hookdeck will include a X-Hookdeck-Will-Retry-After header in the request headers. This header indicates the number of seconds that the next retry will be scheduled in once your server responds, assuming that a retry is applicable. If there's no X-Hookdeck-Will-Retry-After then the request is the last automatic retry.

Scheduling a automatic retry

Your destination can respond with a Retry-After header to indicate how long Hookdeck should wait before retrying the event. This can be useful to implement custom retry logic or scheduling of retries based on specific errors. The Retry-After header must be an integer value representing the number of seconds to wait before retrying the request, a valid date string as per the HTTP spec or a ISO string.

Returning a value of -1 will cancel any further automatic retries.

If your destination returns a Retry-After header, the value will take precedence over any retry rule. You don't need to set a retry rule in order to use the Retry-After header.

Using the Retry-After header, a retry can be scheduled up to 7 days in the future and at most 50 times.

Viewing the next attempt

To determine when a specific event will be retried, locate the event and note its Next Attempt At property.

Cancel scheduled retries

Canceling an automatic retry will prevent all future scheduled retries from occurring on an event.

  1. Locate the event whose automatic retries you wish to cancel.
  2. On the event, click X to cancel the retry.
PUT /events/:id/mute
<- Previous Filters Next -> Requests