Webhook retries and pauses

Receivers go down. Embers assumes yours will, retries on a fixed schedule, and gives up in a way you can see and undo.

The schedule

One initial attempt plus seven retries, eight attempts in total.

The final attempt lands roughly 6.3 days after the first one. Slack and HubSpot deliveries use the same schedule.

What counts as success, and what is retried

Any 2xx response is a success, and Embers stops there. Return one as soon as you have the body, then do slow work in the background.

Retried: network failures, 408, 425, 429, and any 5xx.

Not retried: every other 4xx. Those are treated as your receiver telling Embers the request is wrong, so trying again would not help. Redirects are not followed, so point the endpoint at the final URL rather than one that forwards.

What pauses an endpoint

Two things pause it, and both stop delivery for the whole endpoint, not just one event.

1. A terminal response. A single non-retryable 4xx pauses the endpoint straight away. A 404, for example, pauses it after one attempt with the reason Endpoint paused after receiving HTTP 404.
2. Exhausted retries. If all eight attempts fail, the endpoint is paused with Delivery retries were exhausted.

A paused endpoint shows the reason in a banner on the endpoint card. Events created while it is paused, while Send events is off, or while your plan does not include webhooks are retained as blocked rather than delivered, so nothing is silently dropped inside the retention window.

HubSpot pauses on its own terminal condition: an authentication failure, which means an invalid or revoked token, a 401, or a 403.

The 30-day log

Delivery history is kept for 30 days, per endpoint, filterable by status and event type. Each delivery shows its state, attempt count, when it was created, the next scheduled attempt, the raw payload, and one row per attempt with the HTTP status, the duration, and the response body.

That window is also the replay window. Anything older is gone.

Replay and resume

1. Fix the receiver first

   Deploy the fix, or correct the URL on the endpoint. Editing a paused endpoint’s URL clears the pause automatically, so you can point it at a corrected receiver and go straight to replaying.

2. Resume the endpoint

   If the URL was already right, use Resume on the endpoint card. The Replay button on a delivery only appears while the endpoint is active and enabled.

3. Replay the deliveries

   Open a Failed or Blocked delivery and choose Replay. Replays use the endpoint’s current URL and current signing secret, which is the point: automatic retries reuse the URL and secret captured when the event was created, so only a manual replay picks up your corrections.

   Earlier attempts stay in the log, and replay attempt numbers continue from the last one rather than starting again at 1.

Troubleshooting

• Paused within seconds of the first delivery. Your receiver returned a 4xx. The usual causes are a signature check that fails on a re-serialised body, an auth layer in front of the endpoint, and a URL that was a dashboard or viewer link rather than the receiving URL.
• Paused after several days. Retries were exhausted, which means the receiver was unreachable or erroring for the whole window. Fix it, resume, and replay the failed deliveries before the 30 days run out.
• Deliveries stay pending. The next attempt time on the delivery tells you when Embers will try again.

Related