WooCommerce Webhook Disabled After Delivery Failures: What to Check

If a WooCommerce webhook has changed to Disabled, start with its last delivery response—not the Active switch. WooCommerce can automatically stop an outgoing webhook after repeated failed deliveries. Open WooCommerce → Settings → Advanced → Webhooks, identify the exact webhook ID and delivery URL, and inspect WooCommerce → Status → Logs → webhooks-delivery. A receiver returning 401, 404 or 500 needs a different fix from a scheduled action that never ran.

Quick path: confirm the webhook was automatically disabled rather than intentionally paused; preserve the latest delivery status and time; repair the receiving endpoint or the documented queue problem; send one controlled test event; then re-enable and verify that a new event arrives once. Do not replay real orders or payments as a diagnostic. Re-enabling does not necessarily recover events that occurred while delivery was disabled.

1. Confirm what Disabled means

WooCommerce distinguishes Active (sends notifications), Paused (deliberately suspended) and Disabled (stopped because of delivery failures). The official webhook guide states that more than five consecutive failures can trigger automatic disabling. It classifies 2xx, 301 and 302 responses as successful for this mechanism; other response statuses are failures. These are WooCommerce’s delivery-status rules, not a guarantee that the receiving application processed an order.

Do not assume the exact transition always occurs on a visually counted fifth retry. Current WooCommerce source uses a stored failure counter and a threshold check, and extensions can change the threshold with woocommerce_max_webhook_delivery_failures. Use the stored status and logs from your installed version, not a guessed count.

In the webhook editor, record its numeric ID, topic, destination host/path, status and the approximate time it stopped sending. Check whether an integration such as Zapier owns the configuration before editing it; an extension may recreate or manage its own webhooks. Do not copy the webhook secret into support tickets, issue comments or public logs.

2. Inspect delivery logs before changing settings

Open WooCommerce → Status → Logs and select the webhooks-delivery source if available. Match entries to the webhook ID, delivery URL and timestamp. Preserve the response code, error class and a sanitized correlation reference. WooCommerce’s webhook API reference describes the request, response and delivery information available for diagnosis.

For a useful comparison, inspect the receiver’s own access/application logs at the same time. Distinguish the outbound attempt reaching the receiver from the receiver accepting and processing it. A quick 200 OK without durable acceptance may still leave a downstream integration broken. Conversely, a receiver may process a request but fail before acknowledging it; a blind replay could duplicate fulfillment, emails or updates.

3. Separate endpoint failures from queue failures

WooCommerce webhook delivery may use background scheduling. That makes failed Action Scheduler jobs relevant only when you can connect a specific job to the webhook ID or the integration’s documented hook. Open WooCommerce → Status → Scheduled Actions, filter by failed/pending status, and inspect the exact action hook, arguments, scheduled time and log messages. Do not infer a link from a nearby timestamp alone.

If the related action is overdue or still pending, follow the scheduled actions not processing guide. If WP-Cron is enabled but the runner does not execute, inspect the trigger-to-runner chain before changing cron configuration. If the action completed, that means its callback finished according to the scheduler, not necessarily that a downstream system accepted and processed the payload.

For queue visibility, Queue Health for Action Scheduler is a read-only diagnostic option when the installed site actually uses Action Scheduler. It can help inspect overdue/failed actions and runner signals; it does not test webhook destination URLs, re-enable disabled webhooks or guarantee delivery. The canonical Webhooks and receiver logs remain the primary evidence.

4. Fix the receiving endpoint before re-enabling

For 401/403, verify that the delivery URL expects webhook POSTs and that its authorization policy matches the integration’s documented design. WooCommerce sends an X-WC-Webhook-Signature header derived from the webhook secret; the receiver must verify the signature against the raw body with its own trusted copy of that secret. Do not disable signature validation to force an HTTP success. A CDN challenge or IP allowlist can also block server-to-server traffic; check logs before loosening rules.

For 404/410, compare the full URL, HTTP method, API version and route including trailing-slash behavior. A browser GET returning 200 on a homepage is not a valid test for a JSON webhook POST. If an endpoint has moved, update the integration through its supported configuration, and confirm that a redirect is acceptable for that specific receiver. WooCommerce’s status classifier may accept 301/302 even when the receiving service never handles the payload; do not treat a redirect as end-to-end success.

For 5xx, timeouts and 429, inspect destination logs, gateway timeouts, server saturation and the receiver’s documented rate limits. Prefer a fast, authenticated acknowledgment only after the receiver has safely accepted the event for durable processing. Do not simply increase the failure threshold to hide a broken endpoint; the same lost-event risk remains.

5. Test recovery without duplicating customer operations

Choose a permitted sandbox or synthetic event and make the receiver observable: record one unique test reference, the expected topic and whether the receiver has accepted it. WooCommerce’s first activation may also send an initial ping; a ping is not proof that an order event or integration workflow works. Confirm one subsequent real workflow-equivalent test, ideally in staging against a test endpoint, using the receiver’s own acknowledgment and processing record.

Once the endpoint is healthy, an authorized store operator can re-enable the disabled webhook in its settings or supported integration. Observe the next controlled delivery and confirm both WooCommerce and the receiver agree. Never publish a real purchase, resend a payment capture, bulk rerun a queue, or call an order-processing webhook manually just to clear the warning. Make the receiver idempotent by design and define how it deduplicates repeated event identifiers before considering any recovery replay.

Important October 2026 caveat: a WooCommerce issue opened on October 26, 2026 reports that a previously disabled webhook may be disabled again after a single later failure because the stored failure count was not reset on reactivation. Treat this as a reported version-dependent issue, not proof that every installed store has the bug. If the same symptom appears, preserve the version, status transitions and logs, check the upstream issue for an applicable fix, and validate on staging. Repeatedly toggling Active does not repair a persistently failing destination.

6. Account for notifications missed during the outage

A webhook being Active again means new eligible events can be delivered; it does not establish that orders, subscriptions, inventory changes or third-party automation missed during the disabled interval were replayed. Define the start/end of the outage from available logs and integration records. Compare the authoritative WooCommerce object records with the receiving system’s state through authorized read-only exports or API reads.

Where a reconciliation gap exists, document affected object IDs privately and choose an integration-specific backfill procedure that is safe against duplicate work. A payment gateway, fulfillment platform, CRM or ERP may apply very different side effects. Require approval and a verified idempotency mechanism before writing missing events or triggering any bulk replays. Webhook delivery is not itself a payment-settlement record.

7. What to send to the integration owner

Provide a concise, redacted case: WooCommerce/plugin versions; webhook ID and topic; destination service name (not credentials); observed Disabled/Active transitions; first/last failed timestamps with timezone; failure response or network error; matching receiver/request IDs; relevant action ID if proven related; and one staging test result. Record whether business events were reconciled separately from the transport fix.

For an integration relying on the built-in WooCommerce webhook mechanism, the WooCommerce Zapier integration guide documents how a missing or disabled webhook and Action Scheduler failures produce different symptoms. That is a useful cross-check, not proof that every webhook belongs to Zapier. Avoid turning on global debugging solely to collect public evidence: depending on the site configuration, raw request/response payloads can contain personal data.

Recovery checklist

• Identified: the exact webhook ID, topic, endpoint and Disabled status are documented.
• Explained: the first failing delivery has a matched receiver or queue-side cause, not just a guessed fix.
• Safely restored: one controlled test reaches and is processed by the receiver exactly as expected.
• Reconciled: the outage interval and any missing business events are independently reviewed; no unapproved replay occurred.
• Observed: later eligible events keep succeeding and the webhook does not return to Disabled.

For more background, see the WooCommerce Webhooks documentation, the developer API reference, and our failed-action diagnostic guide. Each addresses a different boundary of the same delivery chain.