WooCommerce disabled your webhook: how to find the failed deliveries and re-send them

<!– target keyword: woocommerce webhook disabled –>

<!– meta description: WooCommerce disables a webhook after repeated failures and hides the payload in its own log. How to find what failed and re-send it. –>

WooCommerce disabled your webhook: how to find the failed deliveries and re-send them

It usually surfaces as a question from someone else. A customer asks why their order has not appeared in the warehouse system. The bookkeeper asks why yesterday’s invoices never landed. Your ERP is missing orders, but nothing in WordPress told you anything was wrong.

The cause is often a webhook that WooCommerce turned off days ago and never announced.

What “disabled” actually means in WooCommerce

WooCommerce’s native webhooks are fire-and-forget. For each event a webhook is subscribed to — an order created, a product updated, a customer changed — WooCommerce queues a single delivery and sends it to your endpoint. If the endpoint answers with a success, the delivery is done. If it answers with anything else, WooCommerce records the failure and counts it against the webhook.

After a handful of consecutive failures, WooCommerce sets the webhook’s status to Disabled. It stays that way. Nothing is queued, nothing is retried, and no order data reaches your endpoint until a human notices and switches it back on. In current WooCommerce the threshold is five consecutive failures, and it can be filtered — but the default behaviour is silent, and that silence is the real problem.

Why you find out days later

Two things work against you.

The first is that the failure count lives on the webhook, in WooCommerce → Settings → Advanced → Webhooks, and nobody watches that screen. The second is worse: WooCommerce’s own delivery log records that an attempt failed and what HTTP status came back, but it replaces the request and response bodies with a placeholder. To see the payload that was actually sent you have to turn on WP_DEBUG — which is not something you want to do on a live store, and which writes to a debug log rather than a screen you can filter.

So the sequence is always the same: the endpoint has a bad hour, the webhook crosses the failure threshold, WooCommerce disables it quietly, and the feed stops. You find out when a human downstream asks a question.

Step 1: Confirm the webhook was disabled

Open WooCommerce → Settings → Advanced → Webhooks. Each row shows a status. A webhook that has been switched off reads Disabled. Find the one your integration uses and check the Delivery URL while you are there, so you are looking at the right row.

Do not simply flip it back to Active yet. If the endpoint is still broken it will fail five more times and be disabled again, and you will have learned nothing.

Step 2: Find out what actually failed

You need the status code and the response the endpoint gave you. WooCommerce shows a status per attempt in its delivery log, but not the bodies. A delivery-log tool can record the status, the response body and the exact request that was sent, which is what you need to tell an endpoint outage apart from a payload problem.

Check whether the endpoint was unreachable — connection refused, DNS failure, timeout — or whether it received the request and rejected it with a 4xx or 5xx and a body. The distinction decides what you fix: the network path, the receiving application, or the payload itself.

Step 3: Re-send the deliveries that were missed

Reactivate the webhook, then re-send what failed. Three things are easy to get wrong.

• Re-activate first. New events need the webhook live. Re-sends are a separate operation.
• Re-send the captured bytes, not a fresh event. If you re-trigger the original action by editing the order, you re-serialise the payload from the order’s current state, which has probably changed. The point is to send the body that was captured at the time.
• Mind duplicates. Re-sending an order the receiving system already has can create a duplicate record. WooCommerce stamps each delivery with an X-WC-Webhook-Delivery-ID header; if you reuse the original ID on the re-send, an endpoint that de-duplicates on that header will discard it. If your endpoint does not, expect a duplicate and reconcile it.

If a webhook’s secret was rotated between the failed attempt and now, the signature on the re-sent payload has to be recomputed with the current secret or the endpoint will reject it. A re-send tool should do that for you.

Step 4: Stop it happening again

Re-sending fixes the hole. It does not stop the next one, and the next one comes from the same design: one attempt, a hard failure count, and silent disabling.

Three changes alter the outcome:

• Automatic retry with backoff. A failed delivery is rescheduled and re-sent a short time later, then with a longer gap, up to a ceiling you set. A blip of a few seconds is absorbed without you doing anything.
• Keeping the webhook active while retries are owed. This is the one that addresses the silent disable directly. While a retry is pending, the failure ceiling is raised, so an endpoint that is down for an hour no longer costs you the webhook; it keeps retrying and resumes normal delivery when the endpoint recovers.
• An alert when it does fail. Retries you cannot see are not much better than no retries. An email to a real address, throttled so a flapping endpoint does not flood the inbox, turns a silent failure into a known one.

Be honest about the trade-off

Keeping a webhook active while it is failing is a deliberate choice with a cost: a permanently dead endpoint keeps accumulating failed deliveries instead of being switched off. If you take that route, alerts and a failure history are not optional extras — they are what stops the protection from hiding a bigger problem. If you would rather WooCommerce disable a dead webhook and make someone notice, leave the default behaviour alone.

What kind of tool fits

If your integration is a one-off and the endpoint rarely fails, the built-in WooCommerce webhooks screen and its status column may genuinely be enough. Fix the endpoint, flip the webhook back on, move on.

If you already run a webhook platform or a general integration service, check the receiving side before adding anything — retries and a delivery log may already exist there.

The remaining gap is a store that pushes order data to an ERP, a 3PL or an accounting tool and needs to see and re-send what failed without standing up another service. That is the category WebhookGuard fills: it observes the native webhooks you already run, stores the request and response bytes core discards, and adds retry and replay on top. It is free and needs no external service.

FAQ

Does reactivating a webhook re-send what was missed?

No. Reactivation only allows new events to be delivered. Failed deliveries have to be re-sent separately.

Will re-sending create duplicate orders in my ERP?

It can, unless the endpoint de-duplicates on the X-WC-Webhook-Delivery-ID header. That header exists for exactly this, but whether your endpoint uses it is up to the endpoint.

Can I see the payload without turning on WP_DEBUG?

Not with WooCommerce’s own delivery log — it redacts the bodies unless WP_DEBUG is on. A delivery-log plugin stores the payload in its own table instead.

How long should I keep failed deliveries?

Long enough to cover your worst outage plus the time it takes someone to notice. Thirty days is a common default; use a shorter window if you watch alerts, a longer one if you do not.

Why not just increase WooCommerce’s failure threshold?

Raising it only delays the disable; it adds no retry. Without a retry behind the higher ceiling you simply get more failures before the same silent stop, which is why the ceiling and the retry belong together.