WooCommerce Webhooks Automatically Disabled After Delivery Failures: Causes and How to Fix It
Quick Answer
WooCommerce automatically changes an active webhook status from Active to Disabled after five consecutive delivery failures. Deliveries fail when the receiving endpoint returns non-2xx HTTP status codes (such as 4xx client errors or 5xx server errors) or when the server times out. Because WooCommerce utilizes Action Scheduler and WP-Cron for background task processing, cron stalls or low traffic can cause sudden delivery backlogs that overwhelm receiving services.

To fix this issue: review the delivery response logs under WooCommerce > Status > Logs, resolve endpoint HTTP errors or timeout limits, and manually set the webhook status back to Active. Developers can also adjust the default threshold using the woocommerce_max_webhook_delivery_failures filter hook.
Symptoms of Disabled Webhooks
When WooCommerce webhooks fail silently in the background, you may experience several operational disruptions across connected systems:
- Third-party services such as CRMs, ERPs, fulfillment platforms, or email marketing solutions stop receiving order updates or customer data.
- The webhook status in
WooCommerce > Settings > Advanced > Webhookschanges from Active to Disabled without triggering an email alert to the admin. - Webhook delivery logs record non-2xx HTTP status codes (such as
404,500, or504) or show execution timeouts. - Order processing automation halts unexpectedly, which can resemble general transactional communication failures such as WooCommerce not sending emails.
Causes of Automatic Webhook Disabling
WooCommerce enforces an internal safety mechanism designed to protect your site and database from being overloaded by continuous failed outbound requests. Understanding why this mechanism triggers involves reviewing four primary causes:
1. Endpoint Failure or Downtime
WooCommerce considers a webhook delivery successful only if the receiving server returns an HTTP 2xx response code or a 301/302 redirect. If the receiving API is temporarily offline, undergoing maintenance, or returning 4xx or 5xx error codes, WooCommerce records a delivery failure. Once five consecutive failures occur, WooCommerce automatically disables the webhook.
2. Request Timeouts
If the receiving server takes too long to process incoming payloads, the outbound HTTP request times out. Severe server performance bottlenecks or proxy timeouts, similar to what occurs during a Cloudflare Error 524, cause WooCommerce to treat unanswered requests as failed delivery attempts.
3. WP-Cron Stalls and Background Batch Processing
Since WooCommerce 3.5.0, webhook events are queued and dispatched asynchronously in the background via Action Scheduler. Action Scheduler relies on WP-Cron (or a system cron job) to process queued jobs. If a site receives low traffic, WP-Cron may not execute regularly. When a visitor finally hits the site, WP-Cron fires off a large batch of backlog tasks at once, which can overwhelm the receiving endpoint and trigger rapid sequential failures.
4. Endpoint URL or Secret Key Mismatches
If an endpoint URL changes, or if secret authentication headers fail on the destination server, the receiving server will reject incoming requests with HTTP 401 Unauthorized or 403 Forbidden status codes. Five rejected notifications in a row will disable the webhook integration.
How to Diagnose Webhook Delivery Failures
Before changing site settings or altering code, run through these diagnostic steps to identify the precise failure cause.
Step 1: Check Webhook Status
- Log in to your WordPress dashboard.
- Navigate to WooCommerce > Settings > Advanced > Webhooks.
- Review the Status column. If a webhook shows Disabled, it was automatically turned off after exceeding the failure threshold.
Step 2: Inspect WooCommerce Delivery Logs
- Navigate to WooCommerce > Status > Logs.
- Use the log drop-down menu to locate logs starting with
webhooks-deliveryor select the specific log file associated with your webhook. - Click View to review the recorded HTTP response codes and payload status for recent requests.
- Identify whether the responses contain HTTP error codes (e.g.,
500 Internal Server Error,404 Not Found) or timeout messages.
Step 3: Review Action Scheduler Logs
- Navigate to WooCommerce > Status > Scheduled Actions.
- Search for actions with the hook name
woocommerce_deliver_webhook_async. - Check for actions marked as Failed or pending backlogs that indicate background execution issues.
Step-by-Step Fixes
Fix 1: Re-enable the Webhook and Verify Endpoint Availability
Once disabled, WooCommerce will not re-enable a webhook automatically even after the receiving server returns to normal operation. You must re-enable it manually.
- Fix the underlying error on the receiving endpoint so that it accepts POST requests and returns an HTTP
200 OKstatus code. - Go to WooCommerce > Settings > Advanced > Webhooks.
- Click on the name of the disabled webhook to edit its configuration.
- Change the Status dropdown from Disabled back to Active.
- Click Save Webhook.
Fix 2: Configure System Cron to Prevent Execution Stalls
To avoid sudden bursts of requests caused by WP-Cron delays, replace default WP-Cron execution with a real system crontab job on your server.
- Open your site's
wp-config.phpfile using FTP or your hosting control panel file manager. - Add the following line above the
/* That's all, stop editing! Happy publishing. */line:
define('DISABLE_WP_CRON', true);
- Log into your hosting account control panel (cPanel, Plesk, or server SSH) and open the Cron Jobs management interface.
- Add a new cron job set to run every 5 minutes with the following command (replace
https://example.comwith your site URL):
wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Fix 3: Adjust the Maximum Delivery Failure Limit (Developers)
If your receiving endpoint experiences brief scheduled maintenance windows, you can increase the failure limit threshold so WooCommerce does not disable the webhook as quickly.
According to WooCommerce documentation, developers can customize default threshold values using the woocommerce_max_webhook_delivery_failures filter hook.
Add the following code snippet to a custom site plugin or your child theme's functions.php file:
add_filter( 'woocommerce_max_webhook_delivery_failures', 'custom_webhook_failure_limit' );
function custom_webhook_failure_limit( $limit ) {
return 10; // Increases failure limit from 5 to 10
}
Caution: Avoid setting this threshold excessively high. If an endpoint is offline permanently, retrying failed deliveries continuously can consume significant database resources and server memory.
Verification
After implementing your fixes, confirm that your webhooks process reliably:
- Navigate to WooCommerce > Settings > Advanced > Webhooks and ensure the target webhook displays an Active status.
- Trigger the webhook event (for example, by updating a test order or creating a test product).
- Return to WooCommerce > Status > Logs, select the current
webhooks-deliverylog file, and verify that the request returned an HTTP 200 response code. - Check the receiving service to confirm that the payload was received and parsed without errors.
Frequently Asked Questions
Does WooCommerce notify store managers when a webhook is disabled?
No. WooCommerce does not send native email notifications when a webhook transitions from Active to Disabled due to failure thresholds. You must monitor log files or use third-party webhook monitoring tools to detect failures early.
Why did my webhook fail if my receiving server was online?
Even if your receiving server is online, failures occur if the endpoint script encounters PHP or database errors while processing the payload, returning a 500 error code. Additionally, intermediate security firewalls or proxy timeouts can abort the HTTP connection before completion.
Comments
Post a Comment