Why the cart stalls on WooCommerce at thousands of products
Action Scheduler, WordPress cron and sync queues: what breaks at volume and how to fix it, from running a store with 15,000 SKUs.
The symptom is always the same and easy to recognise: the store behaves normally, then during a campaign or a stock sync, adding to cart starts taking ten seconds and some orders sit in “pending” without payment. The server isn't too small. A queue is eating the whole CPU.
Who actually runs the scheduled jobs
WordPress has no real scheduler. It has wp-cron.php, which fires on visits to the
site. On a low-traffic store that means jobs run rarely; on a busy one it means your visitors pay for
their execution with their own load time.
On top of that, WooCommerce adds Action Scheduler — its own queue, kept in the database, holding stock syncs, emails, price updates and everything plugins do in the background. At 15,000 products and a daily supplier sync, that queue can reach tens of thousands of actions. Every visit to the site tries to move it along.
What breaks, in the order it breaks
- Action Scheduler tables grow without limit, because completed actions aren't deleted by default.
- Queries against those tables get slow, and every page request waits behind them.
- Cart and checkout, which can't be cached, are the first to feel it.
- PHP processes pile up, the server hits its process limit, and the rest of the requests queue.
The fix, in four steps
1. Stop the cron that visitors trigger
In wp-config.php add define('DISABLE_WP_CRON', true); and set a real
system cron calling wp-cron.php every minute. From that moment, jobs are no longer paid
for by visitors, and execution becomes predictable.
2. Clean the queue, and keep it clean
Check the number of completed Action Scheduler actions. If it's in the tens of thousands, delete them and shorten the retention period. A healthy queue holds under a few thousand rows at any moment.
3. Sync in batches, not all at once
An import touching 15,000 products in a single run will hit the time limit and restart, sometimes forever. Break it into batches of a few hundred, with a pause between them, and run it in your quietest window. And if your supplier gives you only the differences, better still: there's no reason to rewrite products that haven't changed.
4. Don't cache the cart, but cache the rest
Category and product pages can be served from cache aggressively. Cart, checkout and account cannot — and must be excluded explicitly, or you get the classic errors with products “disappearing” from the cart. An object cache layer, Redis-style, cuts repeated queries dramatically.
How you know it's fixed
Measure three things, before and after: response time on add-to-cart, the number of pending actions in the queue, and the number of active PHP processes at peak. If the first drops under a second, the second under a thousand and the third stops hitting the limit, you're done. If not, the problem is elsewhere — and then a load test is worth it, because it shows you exactly what gives first.