WooCommerce webhook disabled automatically due to delivery failure: How to reset

WooCommerce automatically disables a webhook when delivery attempts continuously fail and reach the consecutive failure threshold (default is 5 consecutive failures). This built-in safety circuit prevents failing endpoints from exhausting PHP process workers, filling wp_options action scheduler logs, and causing database bloat. When the receiving server responds with HTTP errors (4xx or 5xx), times out (greater than 10 seconds), or drops connection, WooCommerce updates the webhook status from active to disabled.

Root Cause Diagnosis

WooCommerce processes webhooks via Action Scheduler (woocommerce_deliver_webhook_async). Each time an event fires, WooCommerce sends an HTTP POST request to the target Delivery URL and tracks the HTTP response status code in the database. If 5 consecutive delivery attempts fail due to receiving endpoint timeouts, SSL/TLS handshake failures, or persistent HTTP error codes, WooCommerce executes WC_Webhook::handle_failure(), setting the webhook status column in wp_wc_webhooks to disabled.

Quick Fix

Reset the webhook status back to active and clear its failure count directly via WP-CLI or SQL query:

# Reset webhook status to active using WP-CLI
wp db query "UPDATE wp_wc_webhooks SET status='active', failure_count=0 WHERE status='disabled';"

Step-by-Step Resolution

1. Identify and Resolve the External Endpoint Failure

Before reactivating the webhook, determine why the target URL rejected or timed out delivery attempts.

1. Navigate to WooCommerce > Status > Logs.
2. Select the log file starting with webhooks- or fatal-errors- from the dropdown list and click View.
3. Locate the failing delivery log entry to check the HTTP response code (e.g., 500 Internal Server Error, 403 Forbidden, 404 Not Found, or cURL error 28: Operation timed out).
4. Ensure the receiving server processes payload requests within 10 seconds and returns an HTTP status code between 200 and 299.

2. Reactivate Webhook via WordPress Admin

If WP-CLI access is unavailable, manually update the status through the WooCommerce control panel:

1. Go to WooCommerce > Settings > Advanced > Webhooks.
2. Click on the title of the disabled webhook.
3. Change the Status dropdown from Disabled to Active.
4. Click Save Webhook.

3. Increase Failure Threshold or Extend Timeouts Programmatically

Prevent WooCommerce from disabling webhooks during temporary endpoint outages by increasing the failure threshold or extending the HTTP timeout via a custom plugin or functions.php.

Add this snippet to your active child theme’s functions.php or a custom MU-plugin (wp-content/mu-plugins/wc-webhook-customs.php):

<?php
/**
 * Plugin Name: WooCommerce Webhook Failure Threshold Tweaks
 * Description: Increases webhook failure limits and HTTP delivery timeouts.
 */

// Increase failure limit from 5 to 15 attempts before disabling
add_filter('woocommerce_max_webhook_delivery_failures', function ($limit) {
    return 15;
});

// Extend HTTP delivery timeout from 10 seconds to 30 seconds
add_filter('woocommerce_webhook_delivery_args', function ($args) {
    $args['timeout'] = 30;
    return $args;
});

4. Manually Flush Pending Failed Action Scheduler Logs

Clear clogged webhook delivery queues to prevent retries from failing immediately upon reactivation:

# Cancel failed webhook actions in Action Scheduler
wp db query "UPDATE wp_actionscheduler_actions SET status='canceled' WHERE hook='woocommerce_deliver_webhook_async' AND status='failed';"

Why This Fails for Some Users

• Persistent Action Scheduler Failures: If Action Scheduler queue execution is broken due to server cron misconfigurations, stale woocommerce_deliver_webhook_async tasks back up. When cron runs next, all accumulated tasks execute at once, immediately hitting the failure limit.
• Cloudflare / WAF Blocking User-Agent: Target endpoints protected by Cloudflare, AWS WAF, or ModSecurity often block the default WooCommerce user-agent (WooCommerce/X.X.X Hookshot (WordPress/X.X.X)), returning a 403 Forbidden response that triggers automatic disabling.
• SSL Certificate Verification Failure: If the target endpoint uses a self-signed, expired, or improperly chained SSL certificate, cURL returns cURL error 60: SSL certificate problem. WooCommerce marks this as a hard delivery failure.
• Database Table Prefix Mismatches: Running the raw SQL quick-fix script without accounting for custom WordPress database prefixes (e.g., using wp_wc_webhooks when the prefix is wp_custom_) will fail to modify rows. Always verify the prefix defined in wp-config.php ($table_prefix).