Inspect and replay webhook deliveries

This guide shows you how to read the webhook delivery log, understand why a delivery failed, replay a delivery to your endpoint (or a debug URL), and re-enable an endpoint after delivery to it stops.

Who can do this: Admins with webhooks:read (view the log) and webhooks:replay (replay deliveries). Re-enabling a stopped endpoint, or resuming a paused one, requires webhooks:write.

Before you start

You need at least one webhook endpoint registered. See Create a webhook endpoint.

Steps

View the delivery log

Go to Admin & Security > Integrations > Webhooks.
Find the endpoint you want to inspect and select ⋮ > View deliveries.
The delivery log opens showing each attempt: Time, Event type, Response status, Attempt number (out of 6), Status badge, and Digest (the payloadDigest you can use to correlate with your receiver logs).
Use the Status, Event, and date filters to narrow the log.
Select any row to expand it. A failed or dead row opens with the cause first — the last HTTP response code, how many attempts have been made, 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”.

Replay a delivery

You can replay any delivery that is within the 30-day replay window.

In the delivery log, find the row you want to replay. Select Replay.
In the confirm dialog, the target defaults to the endpoint’s original URL. To replay to a debug server instead, enter an HTTPS URL in the Debug URL field.
Select Replay to confirm.

A new pending delivery row appears in the log. The replay fires on the queue — it is asynchronous, not instant. The HMAC signature is regenerated at the current timestamp, so your receiver’s five-minute tolerance window does not reject it (the signature will differ from the original).

For deliveries older than 30 days, the Replay action is disabled and shows “Past replay window (30 days).”

Re-enable a stopped endpoint

When a delivery fails its sixth attempt, or your receiver answers 410 Gone, delivery to the endpoint stops: its status becomes failing, shown as Delivery stopped, and every active admin of your organization whose role includes View webhooks (webhooks:read), up to ten, is emailed. The detail page shows a red banner: “Delivery stopped — a delivery failed all 6 attempts, or your receiver answered 410 Gone. Up to 10 admins whose role can view webhooks were emailed when delivery stopped. Fix your receiver, then Re-enable.” (A paused endpoint is resumed instead, from its ⋮ menu on the Webhooks list.)

Fix the issue on your receiver that caused the failures (for example, a misconfigured HMAC secret or a server that was returning 500).
On the endpoint detail page, select Re-enable.
Read the confirmation: “Re-enabling resumes delivery from active. Past failed deliveries are not auto-resent — use Replay for those.” Select Re-enable to confirm.

The endpoint returns to active status and the Delivery stopped banner clears. New events are delivered again; events that occurred while delivery was stopped were not kept and are not sent. If you also need the failed deliveries re-sent, replay them individually (see above).

Verify

For a replayed delivery: a new row with pending status appears in the log. Once it resolves, the status updates to delivered or failed.

For a re-enabled endpoint: the “Delivery stopped” banner clears and the status badge shows “Active.”

If something goes wrong

Replay is disabled with “Past replay window” — the delivery is older than 30 days and cannot be replayed. Use your own records or application state to handle the missed event.
The replay to a debug URL also fails — the debug replay produces its own row in the log with its own response code. Check that debug URL for the cause.
Delivery stopped again after re-enabling (the admins who can view webhooks get another email) — the underlying issue on your receiver was not resolved. Check the failure detail (expand the failed rows to read the response code) and fix your receiver before re-enabling again.
Re-enable is not visible — your role may lack webhooks:write. Contact your organization’s owner.