# Webhook endpoint is paused

URL: https://useembers.com/help/troubleshooting/webhook-endpoint-paused/
Category: Troubleshooting
Plan: Solo and above
Updated: 2026-09-12
Last verified: 2026-09-12

> Why Embers auto-pauses an endpoint on a 4xx or after retries run out, how to read the delivery log, fix the receiver, replay, and resume.

An endpoint that keeps rejecting deliveries gets paused rather than retried forever. In **Developer**, then **Webhooks** (`/developer/webhooks`), the endpoint shows a **Paused** badge and a banner with the reason, followed by the instruction to correct the URL and save, or resume the endpoint, before replaying a delivery.

> **Warning: Solo and above, administrators only**
>
> Webhook endpoints require Solo or above and an account administrator. An account can configure up to 10 endpoints.

## The two ways an endpoint pauses

**A terminal 4xx pauses immediately.** Anything outside `408`, `425`, and `429` is treated as your receiver telling Embers the request is wrong, so retrying it would only repeat the rejection. A `404` pauses after a single attempt with `Endpoint paused after receiving HTTP 404.`

**Exhausted retries pause afterwards.** Network failures, `408`, `425`, `429`, and any `5xx` are retried seven times after the initial attempt. The first retry is 30 seconds later and the last lands about 6.3 days after the original. When they all fail the endpoint pauses with `Delivery retries were exhausted.`

Embers accepts any `2xx` as success and does not follow redirects, so a `301` or `302` to your real handler counts as a failure.

## Read the delivery log first

Open the endpoint and look at its delivery history before changing anything. Each row carries the event type, the state, the HTTP status, the attempt count, the last attempt time, and the error. History is kept for **30 days**, and you can filter by state and by event type.

| State | What it means |
| --- | --- |
| `delivered` | Your endpoint answered `2xx` |
| `failed` | Terminal, either a 4xx or the last retry |
| `blocked` | Created while the endpoint was paused, disabled, or not available on your plan. It was retained, not sent |

The status column usually names the fix on its own. A `404` is a wrong path, a `401` or `403` is your own authentication rejecting Embers, a `400` is a body your handler cannot parse, and a wall of `5xx` is your service falling over on the request.

## Fix the endpoint

### Confirm the URL is a receiving URL

It must be public HTTPS on port 443. URLs containing a fragment are rejected, because browsers never send fragments and neither does an HTTP client. On a service such as Webhook.site, copy the unique receiving URL, not the dashboard URL you are looking at.

### Answer fast and answer 2xx

Acknowledge the request, then do your work asynchronously. A handler that processes the lead before responding will time out under load and turn a healthy endpoint into an exhausted one.

### Verify the signature correctly

If your handler rejects unsigned or badly signed requests, verify the Standard Webhooks headers over `webhook-id.webhook-timestamp.body` using the raw body. Reframing the JSON before verifying is the most common cause of self-inflicted 401s. See [Verify webhook signatures](/help/integrations/verify-webhook-signatures/).

### Deduplicate on webhook-id

Delivery is at least once and retries can arrive out of order, so a replay may deliver an event your system already has.

## Resume and replay

Editing a paused endpoint's URL and saving **clears the pause automatically**, which is the path to use when the receiver moved. If the URL was right and the receiver was simply down, press **Resume** instead.

Once the endpoint is active again, the retry control appears on rows in a `failed` or `blocked` state. It is deliberately hidden while the endpoint is paused or disabled, so you cannot replay into a receiver that is still broken.

> **Note: Replays use current settings, automatic retries do not**
>
> An automatic retry uses the URL and signing secret captured when the event was created. A manual replay uses the endpoint's current URL and current signing secret, which is what makes "fix the URL, then replay the backlog" work. Earlier attempts stay in the log and the replay's attempt number continues from the last one.

## What your team sees

Account administrators receive a security email whenever an endpoint is created, updated, removed, paused, resumed, or has its secret rotated. The notice names the endpoint, the workspace, the destination hostname, who acted, and what changed. It never includes the URL path, query credentials, or the signing secret. Saving an unchanged endpoint sends nothing.

## Related

- [Signed webhooks](/help/integrations/webhooks/): Create an endpoint and choose its events.

- [Retries and pauses](/help/integrations/webhook-retries-and-pauses/): The full retry schedule and pause rules.

- [Verify webhook signatures](/help/integrations/verify-webhook-signatures/): Check the HMAC without breaking your handler.