Webhook endpoint is paused

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.

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.

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

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

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

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

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

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