# Webhook retries and pauses

URL: https://useembers.com/help/integrations/webhook-retries-and-pauses/
Category: Integrations
Plan: Solo and above
Updated: 2026-10-28
Last verified: 2026-10-28

> How Embers retries a failed webhook delivery across eight attempts and about 6.3 days, what pauses an endpoint, and how to resume it and replay events.

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.

> **Warning: Solo and above, administrators only**
>
> The delivery log, **Replay**, and **Resume** are on the Webhooks page (**Integrations** in the sidebar, then the **Webhooks** row, `/integrations/webhooks`) and under Settings, then API and webhooks, then Webhooks (`/developer/webhooks`), on Solo or above, for workspace admins. [Send lead events to your own endpoint](/help/integrations/webhooks/) covers setting one up.

## The schedule

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

| Attempt | Sent after the previous one |
| --- | --- |
| 1 | Immediately |
| 2 | 30 seconds |
| 3 | 2 minutes |
| 4 | 10 minutes |
| 5 | 1 hour |
| 6 | 6 hours |
| 7 | 24 hours |
| 8 | 5 days |

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](/help/integrations/verify-webhook-signatures/). Slack, HubSpot, Salesforce, Pipedrive, Attio, 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 API and webhooks, 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).

Events created while the workspace's plan does not include webhooks are kept as **Blocked** too, for example when a trial ends while a scan is still finishing. Those are sent on their own once the plan includes webhooks again: within about five minutes, oldest first, for events up to 30 days old, to the endpoint's current URL and signing secret, while the endpoint is switched on and not paused. A lead event goes out only if the person is still a lead (they still match your ideal customer profile and their company is not on your [blocklist](/help/leads/company-blocklist/)); a test event is never sent later. Events blocked because the endpoint was paused or switched off are not sent on their own; replay them.

## 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 API and webhooks, 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

### 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.

### 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.

### 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 API and webhooks, 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.

> **Note: Expect duplicates**
>
> Delivery is at least once. If your receiver stores an event but answers too slowly, Embers counts a failure and sends it again. Deduplicate on the `webhook-id` header, which is the same on every retry and replay.

## 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](/help/troubleshooting/webhook-endpoint-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 reads Retrying.** It failed and is waiting for its next attempt. **Next attempt** in **Delivery details** says when. **Queued** means it has not been tried yet, or its first attempt is on its way. Neither can be replayed: Embers is still sending it.

**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, Salesforce, Pipedrive, Attio, Notion, Google Sheets, and HeyReach have their own pause reasons: see [Slack delivery is paused](/help/troubleshooting/slack-delivery-paused/), [HubSpot delivery is paused](/help/troubleshooting/hubspot-delivery-paused/), [Salesforce delivery is paused](/help/troubleshooting/salesforce-delivery-paused/), [Pipedrive delivery is paused](/help/troubleshooting/pipedrive-delivery-paused/), [Attio delivery is paused](/help/troubleshooting/attio-delivery-paused/), [Notion delivery is paused](/help/troubleshooting/notion-delivery-paused/), [Google Sheets delivery is paused](/help/troubleshooting/google-sheets-delivery-paused/), and [HeyReach delivery is paused](/help/troubleshooting/heyreach-delivery-paused/).

## Related

- [A webhook endpoint is paused](/help/troubleshooting/webhook-endpoint-paused/): Work through each pause reason in order.

- [Send lead events to your own endpoint](/help/integrations/webhooks/): Create an endpoint and read its delivery log.

- [Verify webhook signatures](/help/integrations/verify-webhook-signatures/): Deduplicate on webhook-id and check the HMAC.

## Frequently asked questions

**What counts as a successful delivery?**

Any 2xx response within about 10 seconds. Redirects are not followed, so a 3xx counts as a failure.

**What happens to events while my endpoint is paused?**

They are kept as Blocked rather than sent, and they stay in the 30-day log where you can replay them once the endpoint is active.

**What happens to events created while my plan could not deliver them?**

If your trial ends or a payment lapses while a scan is still finishing, its events are kept as Blocked. Once your plan includes webhooks again, Embers sends them on its own within about five minutes, to the endpoint's current URL and signing secret, as long as the endpoint is on and the lead is still a lead.

**Does one rejected event pause my endpoint?**

No. A 400, 409, or 422 fails only that event and the rest keep flowing. Five in a row with no successful delivery in between pause the endpoint.

**Does a replay get its own retries?**

Yes. A replay starts a fresh cycle of up to eight attempts, using the endpoint's current URL and signing secret.