Managing WooCommerce Scheduled Actions (Cron Jobs) Without Crashing Your Server

Managing WooCommerce scheduled actions without crashing your server comes down to three things: replacing WP-Cron with a real system cron, capping how much work Action Scheduler claims at once, and keeping the queue tables from growing into the millions of rows. Most stores that fall over during a sale aren’t failing because of traffic. They’re failing because a backlog of pending background jobs decided to run all at once while customers were checking out.

This guide walks through how the scheduling layer actually works, what to look at first, and the specific limits we adjust on busy stores.

WP-Cron and Action Scheduler are not the same thing

WordPress has two overlapping systems for background work, and mixing them up is the usual reason a fix doesn’t stick. Knowing which one owns a task tells you where to look when something stalls.

WP-Cron

WP-Cron is WordPress core’s scheduler, and it is not a real cron daemon. It fires on page loads: a visitor hits your site, WordPress checks whether any scheduled events are due, and spawns a loopback request to run them. The WordPress developer documentation on cron spells out this dependency on traffic, which cuts both ways. A quiet store never runs its jobs, and a busy store can trigger the same check thousands of times an hour.

Action Scheduler

Action Scheduler is the queue library bundled with WooCommerce, Subscriptions, and dozens of other plugins. It stores each job as a row in the database (wp_actionscheduler_actions, with companion logs, claims, and groups tables) and processes them in batches. WP-Cron kicks it off through the action_scheduler_run_queue hook roughly every minute, so Action Scheduler inherits every WP-Cron weakness while adding its own throughput knobs. You can read the library’s own reference at actionscheduler.org.

Why a queue takes down a server

Each claimed action runs as a full PHP process with WordPress loaded, which typically means 40 to 120 MB of memory and a handful of database queries per action. Multiply that by concurrent batches and you can consume every available PHP worker in seconds. Common triggers we see:

• A recovered backlog. The site was quiet or WP-Cron was broken for two days, 60,000 pending actions piled up, and then they all become due at once.
• Subscription renewals clustered on the 1st of the month, each firing payment gateway API calls that hold a worker open for 2 to 10 seconds.
• Failed actions retrying in a loop because an external API is timing out.
• Bloated tables. Millions of completed rows make every claim query slow, so the scheduler spends its time reading the database instead of doing work.
• Loopback storms from high traffic, where wp-cron.php requests compete with real customers for the same PHP pool.

Step 1: Read the queue before changing anything

Open WooCommerce > Status > Scheduled Actions and note the counts for pending, in-progress, failed, and complete. Healthy stores usually sit under a few thousand pending at any moment, with in-progress in single digits. If you see 50,000 pending or hundreds stuck in-progress, you have a throughput problem, not a configuration preference.

From the command line, wp action-scheduler status gives the same picture in one line, and it’s the fastest way to check whether a change helped. Also look at what’s queued: one plugin generating 90% of the actions is worth investigating before you scale hardware.

Step 2: Move to a real system cron

Disabling the traffic-dependent trigger is the single highest-impact change on a store doing real volume. Add this to wp-config.php:

define( 'DISABLE_WP_CRON', true );

For a closer look at this topic, see our guide: Shopify vs. WooCommerce: The Total Cost of Ownership in 2026.

Then schedule a server-side job. A one-minute interval suits most WooCommerce stores, and five minutes is fine for low-volume shops:

• * * * * * cd /path/to/site && wp cron event run --due-now --quiet for WordPress core events.
• Optionally add wp action-scheduler run --batches=2 --batch-size=25 as a separate entry when the queue needs extra help.

The benefit is predictability. Jobs run on a schedule you control, at a CPU cost you can measure, instead of piggybacking on customer page views. Managed platforms often do this for you, which is one of the differences worth checking on any WooCommerce hosting plan you’re comparing.

Step 3: Tune batch size, concurrency, and time limits

Action Scheduler ships with conservative defaults: 25 actions per batch, 1 concurrent batch, and a 300 second time limit per queue run. Those numbers are safe, not fast. Adjust them to match your PHP worker count, never past it:

• action_scheduler_queue_runner_batch_size to raise batches to 50 or 100 for light, fast actions such as status updates or email logging.
• action_scheduler_queue_runner_concurrent_batches to allow 2 or 3 parallel batches if you have 8 or more PHP workers and headroom on CPU.
• action_scheduler_queue_runner_time_limit to shorten runs on shared infrastructure so a single stuck job can’t hold a worker for five minutes.
• action_scheduler_failure_period to control how long an action can sit in-progress before it’s marked failed. The default is 300 seconds.

Change one value, watch server load for 30 minutes, then change the next. Raising concurrency on a box with four workers is how you turn a slow queue into a 502 page.

Step 4: Clear a backlog safely

Deleting rows straight out of the database is tempting and usually a mistake, because renewals and pending payments live in that table too. Work through it in order instead:

1. Fix the cause first. If an API is timing out, drain the queue and the failures come right back.
2. Run the queue hard from the CLI: wp action-scheduler run --batches=20 --batch-size=50. Run it in a screen session and watch load average.
3. Delete only completed and failed history with wp action-scheduler clean --batch-size=1000, which respects the retention window.
4. Cancel obsolete pending groups you genuinely don’t need, using wp action-scheduler cancel filtered by hook or group.
5. Repair broken recurring schedules with wp action-scheduler fix-schedule after a botched migration.

Step 5: Keep the tables lean

Action Scheduler purges completed actions older than 30 days by default. On a store logging 100,000 actions a week that’s still millions of rows, so shortening retention with action_scheduler_retention_period to 7 days (604800 seconds) keeps claim queries quick. Pair it with periodic index checks, since a slow claim query throttles every batch behind it. Our notes on optimizing WooCommerce database tables go deeper on the indexing side.

Monitoring so you find out before your customers do

Through 2025 the pattern in nearly every emergency ticket we handled was the same: nobody was watching queue depth until checkout broke. Track three signals and you get days of warning.

• Pending count trend. A number that climbs every hour means throughput is below intake.
• Oldest pending action age. Anything more than 15 minutes past due needs attention.
• Failed actions per hour, alerted above a threshold you pick, since failures usually point at an integration rather than the server.

Cron pressure also interacts with caching. When background jobs invalidate product or cart fragments constantly, your hit ratio drops and PHP does more work per visitor, which is covered in our breakdown of server-level caching strategies for dynamic pages. Locking down the endpoint matters too, as we note in the WooCommerce security features a host should handle for you, because wp-cron.php is a favourite target for cheap request floods.

Frequently Asked Questions

How often should WooCommerce cron jobs run?

Every minute is the standard interval for a system cron on an active store, and every five minutes is acceptable below roughly 50 orders a day. Action Scheduler expects its runner to be triggered at least once a minute to keep pending actions moving on schedule.

Is it safe to delete rows from the Action Scheduler tables?

Deleting completed and failed rows is safe; deleting pending rows is not, because subscription renewals and payment retries are stored there. Use wp action-scheduler clean or shorten the retention period rather than truncating wp_actionscheduler_actions directly.

Why do my scheduled actions stay stuck in “pending”?

The most common cause is a blocked loopback request, so WP-Cron never fires the queue runner at all. Test it under Tools > Site Health, and if loopbacks fail, switch to a real system cron with DISABLE_WP_CRON set to true.

Does raising the batch size make the queue faster?

It helps only if you have spare PHP workers, memory, and database capacity. On a server with four workers, moving from 25 to 100 actions per batch often increases per-batch runtime without improving actions completed per minute, and it raises the odds of a timeout.

Can I run Action Scheduler entirely from WP-CLI?

Yes, and on high-volume stores that’s the better setup. Disable the WP-Cron trigger, then run wp action-scheduler run from a system cron with explicit batch and concurrency values so background work never competes with front-end traffic.

Want your background jobs handled at the server level?

We configure system cron, queue monitoring, and PHP worker limits for every store we host, so scheduled actions keep moving without touching checkout performance. Talk to our team about your current queue depth and we’ll tell you what your store needs.