Skip to content
MapleGatherMapleGather Help

Webhook deliveries failing or dead

Your webhook endpoint is showing a “Retrying” banner or a “Delivery stopped” status, or you are seeing failed or dead rows in the delivery log.

What’s happening

Section titled “What’s happening”

Retrying banner (on an active endpoint): some recent deliveries to your endpoint got no 2xx response — your receiver answered with an error, or did not answer in time — and are waiting for their next attempt. The endpoint is still active and MapleGather keeps retrying. No email is sent for this; the banner is the early warning.

Delivery stopped (endpoint status failing): MapleGather tries each delivery up to six times over about a day. When a delivery’s sixth attempt fails, or your receiver answers 410 Gone on any attempt, that delivery becomes dead and delivery to the whole endpoint stops. The same happens if MapleGather stops before it records the result of a delivery’s last attempt (for example, the server sending it stopped mid-attempt). At that moment MapleGather emails every active admin of your organization whose role includes View webhooks (webhooks:read), up to ten, naming the endpoint, the event type and the last response. The email shows only the start of the endpoint’s address (its scheme and host) and its last four characters — a receiver URL can carry a secret, so the path and query are never emailed. While delivery is stopped, new events are not sent to the endpoint and are not kept to send later, and retries already scheduled for it are not sent (those deliveries become dead too). You must re-enable the endpoint after fixing your receiver.

There is no setting for how many failures trigger the email: it is sent once, when delivery stops. Failures that are followed by a successful retry never send one.

How to fix it

Section titled “How to fix it”
  1. Go to Admin & Security > Integrations > Webhooks.
  2. Find the failing or dead endpoint and select ⋮ > View deliveries.
  3. In the delivery log, expand a failed or dead row. The detail opens with the cause: the last HTTP response code (for example, 500, or “no response”), the attempt count, and when the next retry will fire. A dead row says why no more attempts will be made: “retries exhausted — dead-letter” (the sixth attempt failed), “receiver answered 410 Gone — no more retries”, or “not retried — the endpoint was paused or stopped when the next attempt came due”.
  4. Use the response code to diagnose the issue on your receiver:
    • 500 — an error in your receiver. Check your server logs for exceptions.
    • 404 — your receiver URL may have changed. Update the endpoint URL using Edit endpoint (webhook_endpoints_update), or create a new endpoint at the correct URL.
    • 401/403 — your receiver is rejecting the request, possibly due to an HMAC signature mismatch. See HMAC signature verification failing.
    • 408/504 — your receiver is timing out. The server-side default timeout is 10 seconds. Reduce your receiver’s processing time or acknowledge the request immediately and handle the work asynchronously.
  5. Fix the issue on your receiver.
  6. If the endpoint shows Delivery stopped, select Re-enable on the endpoint detail page (or in the endpoint’s ⋮ menu on the Webhooks list). Read the confirmation (“Re-enabling resumes delivery from active. Past failed deliveries are not auto-resent — use Replay for those.”) and confirm.
  7. To recover missed deliveries, replay them individually from the delivery log. Select Replay on each delivery row. Deliveries older than 30 days cannot be replayed.

If the endpoint is still active with the Retrying banner: once your receiver starts returning 2xx, those deliveries succeed on their next attempt and the banner no longer shows when you reload the log — no re-enable needed.

If that didn’t work

Section titled “If that didn’t work”

If delivery stops again after re-enabling (and the admins who can view webhooks get another email), the underlying issue on your receiver was not fully resolved. Check the new failure rows in the delivery log for the response code and try again.

For persistent HMAC verification failures, see HMAC signature verification failing.

If the response codes don’t explain it, check your receiver’s own access logs for MapleGather’s requests — each carries an X-Webhook-Event header. A delivery counts only when MapleGather connects within 3 seconds and your receiver answers with a 2xx within 10 seconds, so a request that never reached your receiver, or one answered too slowly, fails even if your code finished the work.

Section titled “Related”