WordPress
WooCommerce cron issues: diagnose delayed scheduled actions and stuck jobs
WooCommerce background work spans WP-Cron, Action Scheduler, payment/webhook retries, email, stock updates, subscriptions, cleanup, and extension jobs. A cron complaint may actually be a failed queue, slow callback, loopback issue, or resource bottleneck.
Inspect Action Scheduler and WP-Cron separately
List pending/failed Action Scheduler actions, hook names, group, age, and error logs. Also list WordPress cron events and overdue hooks. Identify the extension that owns each queue before deleting or rerunning items.
A high pending count with normal throughput may simply reflect a busy batch; age and failure rate add context.
Find the blocking action
Look for repeated failures, long execution, database locks, remote API timeouts, PHP memory/timeouts, or a job creating new jobs faster than workers complete them.
Payment/subscription actions can have real financial effects; do not bulk rerun them without understanding idempotency.
Use a reliable scheduler trigger
On production stores, a system scheduler calling WordPress/Action Scheduler can provide more predictable execution than relying only on visitor traffic. Ensure overlapping invocations are safe and the hosting account has enough PHP/database capacity.
Keep staging from running live WooCommerce schedules against real payment/email endpoints.
Monitor queue age after the fix
Confirm old actions drain, new actions complete on time, failed count stabilizes, and storefront/admin latency remains healthy. Add alerts based on queue age and failures; total queue count alone can be misleading.
- Separate WP-Cron and Action Scheduler.
- Identify owning extension.
- Protect financial job idempotency.
- Monitor queue age and failures.