Webhook retries and pauses

Receivers go down. Embers retries a failed delivery on a fixed schedule, pauses the endpoint when retrying would not help, and keeps every event for 30 days so you can replay it once the receiver is fixed.

The schedule

One attempt plus up to seven retries, eight attempts in total:

The last attempt lands about 6.3 days after the first. Each attempt is signed as it is sent, so its webhook-timestamp is current and passes a timestamp tolerance check. Slack, HubSpot, HeyReach, Instantly, Smartlead, and Emelia deliveries use the same schedule.

What succeeds, and what is retried

Success: any 2xx. Embers waits about 10 seconds for a response. Acknowledge first, then do slow work in the background.

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

Not retried: every other status, including every other 4xx and every 3xx. Embers does not follow redirects, so register the final URL rather than one that forwards.

What pauses an endpoint

A pause stops delivery of every event, not only the one that failed, so Embers pauses only when the receiver itself looks broken:

• A non-retryable response about the endpoint. One 3xx, or one 401, 403, 404, 410, or other 4xx outside the retried set and the rejected-event set below, pauses the endpoint after a single attempt. A 404 shows Endpoint paused after receiving HTTP 404.
• Five rejected events in a row. A 400, 409, or 422 means your receiver refused that one event’s payload. The event is marked Failed after one attempt, with the response in its log, and every other event keeps flowing. When five events in a row are refused like that with no successful delivery in between, the receiver is refusing everything, and the endpoint pauses with Endpoint paused after 5 deliveries in a row were rejected (last: HTTP 422). One successful delivery resets the count.
• Exhausted retries. When all eight attempts fail, the endpoint pauses with Delivery retries were exhausted.

A paused endpoint shows a Paused badge, and administrators get an email. On the Webhooks page the status reads, for example, “Delivery to Zapier is paused”, and Needs attention gives the reason; under Settings, then Developer, the reason is in a banner. While it is paused, Send test is unavailable, new events and retries that come due are kept as Blocked, and nothing is dropped inside the 30-day window. The same happens while the endpoint is switched off (Send events in its editor), or while the workspace’s plan does not include webhooks.

The 30-day log

Each endpoint keeps 30 days of history: Activity on the Webhooks page, filtered All or Failed, and Recent deliveries under Settings, then Developer, filterable by status and event. A webhook delivery is never held back; Blocked ones are listed under All. Each delivery’s Delivery details shows its state, attempt count, created time, next scheduled attempt, payload, and one row per attempt with the HTTP status, duration, and the start of the response body. Anything older than 30 days is deleted and cannot be replayed.

Resume and replay

1. Fix the receiver

   Deploy the fix, or correct the URL. Saving a new URL on a paused endpoint clears the pause, so you can go straight to replaying.

2. Resume the endpoint

   If the URL was already right, choose Resume: beside the endpoint under Needs attention, or in its … menu. Replay only appears while the endpoint is active and switched on.

3. Replay the deliveries

   Needs attention lists the newest three failed deliveries across every endpoint, each with Replay. For the rest, pick the endpoint under Activity, filter by Failed (Blocked deliveries are under All), and choose Replay on each one to resend. Under Settings, then Developer, filter Recent deliveries by Failed or Blocked instead. A replay uses the endpoint’s current URL and current signing secret, while automatic retries keep the URL and secret captured when the event was created. That is why fixing the URL and replaying works.

   A replay starts a fresh cycle of up to eight attempts. Earlier attempts stay in the log, and attempt numbers continue from the last one. If the replay fails with a response that pauses, the endpoint pauses again. Resuming a paused endpoint, saving a corrected URL for it, or switching delivery back on starts the count of rejected events from zero. The endpoint pauses again only after five more rejected deliveries in a row.

Troubleshooting

One event Failed but the endpoint is still Active. Your receiver answered 400, 409, or 422 for that event. Open Delivery details, read the response body, fix the handler or the data, and Replay it.

Paused seconds after the first delivery. Your receiver answered with a 4xx such as 401, 403, or 404, or a redirect. The usual causes are a signature check hashing re-serialised JSON, an authentication layer in front of the receiver, and a dashboard URL registered instead of the receiving URL. A webhook endpoint is paused walks through each.

Paused after several days. Every attempt failed, so the receiver was unreachable, slow, or erroring for about 6.3 days. Fix it, resume, and replay before the 30 days run out.

A delivery stays Pending. It is waiting for its next attempt. Next attempt in Delivery details says when.

Replay is missing. The endpoint is paused or switched off, or the delivery already succeeded. Only Failed and Blocked deliveries can be replayed.

A native destination paused instead. Slack, HubSpot, Notion, and HeyReach have their own pause reasons: see Slack delivery is paused, HubSpot delivery is paused, Notion delivery is paused, and HeyReach delivery is paused.

Related