Troubleshooting WooCommerce Webhook Delivery Failures & Action Scheduler Timeouts

WooCommerce webhooks are critical for integrating modern e-commerce stores with external systems—from ERPs and CRMs to custom fulfillment APIs. However, when stores experience sudden spikes in order volume or inventory syncs, webhook deliveries can start failing silently. Under the hood, WooCommerce relies on the Action Scheduler library to process these background tasks.

In this deep-dive diagnostic guide, we’ll explore why WooCommerce webhooks fail due to Action Scheduler timeouts, how to identify the root cause using error logs, and the advanced CLI commands and configuration tweaks required to resolve the bottleneck.

The Symptoms: Silent Failures and Swelling Queues

When webhook deliveries fail, store administrators typically notice that external systems are no longer receiving real-time order updates. Upon inspecting the WooCommerce > Status > Webhooks screen, you might see webhooks unexpectedly disabled or failing.

Digging deeper into the wp-content/uploads/wc-logs/ directory, you’ll likely uncover fatal errors in the PHP error logs or WooCommerce fatal error logs:

[21-Sep-2026 09:12:45 UTC] PHP Fatal error: Uncaught RuntimeException: Error saving action: Error saving action: Maximum execution time of 60 seconds exceeded in /var/www/html/wp-content/plugins/woocommerce/packages/action-scheduler/classes/migration/ActionScheduler_DBStoreMigrator.php:44
Stack trace:
#0 /var/www/html/wp-includes/class-wp-hook.php(324): ActionScheduler_QueueRunner->run()

Additionally, checking the WooCommerce > Status > Scheduled Actions tab will reveal a massive backlog of Pending actions, with many older tasks stuck in the In-progress or Failed states.

Diagnosing the Action Scheduler Bottleneck

The Action Scheduler processes tasks in batches during a WP-Cron request. If an external API takes too long to respond to a webhook payload, the PHP script can easily hit its max_execution_time. When this happens, the batch fails, the WP_Cron lock remains active, and subsequent tasks begin piling up.

1. Inspecting the Queue via WP-CLI

The WordPress dashboard can struggle to load the Scheduled Actions screen if the queue contains hundreds of thousands of tasks. We turn to WP-CLI for a reliable snapshot:

# Check the status of all scheduled actions
wp action-scheduler status

# Output:
# +-------------+-------+
# | status      | count |
# +-------------+-------+
# | complete    | 1245  |
# | pending     | 45210 |
# | in-progress | 3     |
# | failed      | 850   |
# | canceled    | 0     |
# +-------------+-------+

A rapidly growing pending count coupled with in-progress tasks that never complete is a classic indicator of timeout loops.

2. Identifying the Culprit Hooks

Next, we identify which specific hooks are clogging the queue:

wp db query "SELECT hook, count(hook) as count FROM wp_actionscheduler_actions WHERE status = 'pending' GROUP BY hook ORDER BY count DESC LIMIT 10;"

# Output:
# +-----------------------------------------+-------+
# | hook                                    | count |
# +-----------------------------------------+-------+
# | woocommerce_deliver_webhook_async       | 42500 |
# | wc-admin_import_orders                  | 1200  |
# | wc_facebook_regenerate_feed             | 850   |
# +-----------------------------------------+-------+

Here, woocommerce_deliver_webhook_async is the clear offender. The external server receiving these webhooks is likely throttling connections or responding sluggishly.

Remediation and Optimization Strategies

To unclog the queue and restore stable webhook delivery, we must tackle the issue from multiple angles: clearing the backlog, extending timeout thresholds, and ultimately decoupling task processing from standard web requests.

Step 1: Force-Running the Queue via CLI

WP-Cron is not designed for heavy background processing on high-traffic sites. To bypass PHP-FPM web request timeouts, we can manually process the queue via SSH using a much higher execution limit:

# Run a batch of actions from the CLI (bypassing HTTP limits)
wp action-scheduler run --batches=5 --hooks=woocommerce_deliver_webhook_async --force

If the external server is simply slow, processing them via CLI ensures they eventually go through without bringing down the web server workers.

Step 2: Increasing Timeouts and Batch Sizes

If you must process them quickly and the external API can handle it, you can use the action_scheduler_queue_runner_batch_size filter to adjust how many tasks are processed per batch, and action_scheduler_queue_runner_time_limit to give the runner more breathing room.

Add the following to a custom Must-Use (MU) plugin (wp-content/mu-plugins/as-tuning.php):

<?php
/**
 * Tune Action Scheduler for high-volume Webhooks
 */

// Increase batch size from default 25 to 100
add_filter( 'action_scheduler_queue_runner_batch_size', function( $batch_size ) {
    return 100;
} );

// Increase time limit for a queue runner instance from 30s to 90s
add_filter( 'action_scheduler_queue_runner_time_limit', function( $time_limit ) {
    return 90;
} );

Step 3: Offloading WP-Cron to the System (Server-Level Fix)

Relying on user visits to trigger wp-cron.php is unreliable. Disable alternate cron and configure a real server-level cron job.

In wp-config.php:

define('DISABLE_WP_CRON', true);

Then, add a system cron job to run Action Scheduler directly (avoiding the general WP-Cron overhead if necessary, or just running standard WP-Cron frequently):

# Edit crontab
crontab -e

# Add entry to run Action Scheduler every minute directly via WP-CLI
* * * * * cd /var/www/html && wp action-scheduler run --quiet > /dev/null 2>&1

Step 4: Scaling the Infrastructure

While tuning the Action Scheduler works for moderate loads, truly enterprise-grade WooCommerce operations—handling massive webhook queues, real-time inventory syncs, and heavy Next.js SSR frontends—will quickly exhaust the I/O and memory limits of shared hosting or basic VPS plans.

When database locks escalate and PHP worker limits are reached, the only sustainable solution is migrating to bare-metal infrastructure. For high-volume e-commerce stores, provisioning Dedicated Servers provides the isolated CPU and RAM required to run continuous background processing without impacting the customer-facing checkout experience. If your target audience or primary fulfillment centers are located in South Asia, deploying on low-latency Dedicated Servers in Pakistan ensures that regional API handshakes for webhooks remain lightning fast, preventing the very timeouts that cause Action Scheduler pileups in the first place.

Conclusion

WooCommerce webhook failures are rarely an issue with WooCommerce itself, but rather a symptom of the Action Scheduler struggling against PHP execution limits and slow external API responses. By diagnosing the queue with WP-CLI, adjusting batch processing limits, implementing system-level cron jobs, and ensuring your underlying server hardware matches your scale, you can build a resilient integration architecture that handles any order volume.