Action Scheduler: 848 past-due actions found; something may be wrong.
WooCommerce shows you that and then leaves you alone with it. It doesn’t say what
is wrong, which plugin caused it, or what to do. This page answers all three —
and the number in your warning doesn’t matter. Six, 263, or ten million, the
causes are the same.
In a hurry? The free StallRadar Past-Due Monitor plugin runs
every check on this page and names your cause in one screen. Or keep reading and
do it by hand — everything it checks is written out below.
Plenty of things on a WooCommerce store don’t happen while you watch. Subscription
renewals, order confirmation emails, stock syncs, abandoned-cart reminders — these
get put on a queue called Action Scheduler and run in the background.
A past-due action is a job whose scheduled time has passed and which still
hasn’t run. One or two is normal under load. Hundreds means the queue has stopped
moving, and the work is piling up rather than happening.
Confusingly, “past due” isn’t a status Action Scheduler stores. That’s why you can’t
find these by filtering the list, and why the warning appears while every row still
says pending.
Is it urgent?
Usually yes, and it’s already been happening for a while by the time you see the
notice. Depending on what your store runs, a stopped queue means:
Subscription renewals aren’t charging — customers keep their access, you don’t get paid
Order emails aren’t sending — confirmations, shipping notices, password resets
Stock isn’t syncing — you oversell items you don’t have
Bookings and reminders never fire
Reports and analytics silently go stale
The jobs aren’t lost. They’re queued, and most will run once the queue moves again —
which is why fixing the cause matters more than clearing the list.
Start here: the 60-second test
Before changing anything, find out which half of the problem you have. Run the queue
by hand once and watch what the number does.
If you have WP-CLI
wp action-scheduler run
If you don’t
Open https://your-site.com/wp-cron.php?doing_wp_cron in a browser
tab, wait for it to finish loading, then reload
WooCommerce → Status → Scheduled Actions.
Actions cleared
Your jobs are fine — nothing is triggering the queue automatically.
This is a scheduling problem. Go to causes 1 and 2.
Nothing cleared
The queue is being triggered but the jobs themselves are breaking. This is a
failing-plugin problem. Go to cause 3.
The six causes, most common first
1
WP-Cron is switched off and nothing replaced it
The cause more often than all the others combined
Someone — a host, a speed-optimisation guide, a previous developer — added a line
to wp-config.php that disables WordPress’s built-in scheduler, and
never set up the real server cron job that was supposed to replace it. The store
works fine. Nothing background does.
How to check
Search wp-config.php for this line:
define( 'DISABLE_WP_CRON', true );
How to fix
Either delete that line, or — better on a busy store — keep it and add a real
cron job in your hosting panel, so the queue runs on a schedule you control:
Common on staging sites, firewalled hosts and sites behind a proxy
WP-Cron works by making an HTTP request to your own site. If that request can’t
get through — a firewall rule, HTTP basic auth on a staging site, a security
plugin, a misconfigured proxy — it fails silently. Nothing is logged and nothing
on the front end looks wrong.
How to check
Tools → Site Health. Look for
“Your site could not complete a loopback request.”
How to fix
Remove HTTP basic auth, or allowlist your own server’s IP
Check any security or firewall plugin for a rule blocking self-requests
If you can’t unblock it, use the real server cron job from cause 1 — it doesn’t depend on loopback
3
The actions are failing, not waiting
A completely different problem with a completely different fix
If your jobs show as failed rather than pending, your
scheduling is working perfectly. A plugin’s job is throwing an error every time
it runs. Clearing the queue or fixing cron will not help — it will just fail
faster.
How to check
WooCommerce → Status → Scheduled Actions → Failed. Note the
hook name, which tells you which plugin owns the broken job:
Hook name starts with
The plugin responsible
woocommerce_scheduled_subscription_
WooCommerce Subscriptions
wc-admin_
WooCommerce Admin / Analytics
woocommerce_run_product_attribute_
WooCommerce core lookup tables
wpforms_
WPForms
mailpoet_
MailPoet
jetpack_
Jetpack
action_scheduler_
Action Scheduler itself
How to fix
Update that plugin first. If it’s already current, turn on
WP_DEBUG_LOG and read wp-content/debug.log while a
batch runs — the fatal error names the file. Then take the hook name and the
error to that plugin’s support forum.
4
The backlog is growing faster than the queue clears it
Typical on high-volume stores, and after a plugin misbehaves once
Action Scheduler processes a limited number of actions per batch. If your store
queues more work than a batch clears, the number climbs forever even though
everything is technically working.
How to check
Note the past-due count, wait ten minutes, and look again. Falling slowly means
you’re under-provisioned, not broken. Rising means something is queueing
faster than it should — usually one plugin scheduling duplicates.
How to fix
Raise how much the queue chews through per run:
add_filter( 'action_scheduler_queue_runner_batch_size', function () {
return 100;
} );
add_filter( 'action_scheduler_queue_runner_concurrent_batches', function () {
return 3;
} );
Raise these gradually. Set them too high on shared hosting and you’ll trip
cause 5 instead.
5
PHP limits are cutting batches off part-way
Silent, and it makes the backlog look permanent
A batch starts, hits max_execution_time or memory_limit,
and dies mid-run. The actions it had claimed go back on the queue, so the same
work is attempted forever and never completes. The count barely moves.
How to check
Look in your PHP error log for timeouts or memory-exhausted fatals with
timestamps that match your cron schedule.
How to fix
Raise the limits if your host allows it, or lower the batch size so each run
finishes inside them — the opposite of cause 4, which is why identifying the
right cause first matters:
add_filter( 'action_scheduler_queue_runner_time_limit', function () {
return 120;
} );
6
The table is too big to recover normally
Rare, but unmistakable once you’re here
Some stores reach millions of rows in
wp_actionscheduler_actions — usually after months of a plugin
queueing duplicates. At that size the admin screen times out just counting them,
and no amount of batch tuning helps.
How to check
SELECT status, COUNT(*) FROM wp_actionscheduler_actions GROUP BY status;
If that query is slow or times out, you’re in this case. Your table prefix may
differ from wp_.
How to fix
Back up the database first. Then delete completed and
cancelled rows in batches — never everything at once, and never the
pending ones, which are real work waiting to happen:
DELETE FROM wp_actionscheduler_actions
WHERE status IN ( 'complete', 'canceled' )
LIMIT 10000;
Repeat until it stops deleting, then fix whichever cause above created them.
The shortcut
Or have all six checked for you
StallRadar Past-Due Monitor is a free WordPress plugin that runs every check on
this page and tells you which cause you have, in one screen.
Names the cause instead of the symptom — WP-Cron, loopback, failures, batch size, PHP limits, table size
Groups your backlog by hook and identifies the plugin behind each one
Separates jobs that are waiting from jobs that are failing
Run the queue, retry failures, or cancel a backlog — cancelling marks rows, never deletes them
Free and open source, GPL-2.0. Works with any plugin that uses Action Scheduler —
WooCommerce, WPForms, MailPoet, Jetpack, Easy Digital Downloads.
What the free version doesn’t do
The free plugin fixes this. It has no memory and no eyes — it only helps when you
open it, which means you find out something broke the same way you did today: after
it already broke. Pro is the part that watches so you don’t have to.
Secure checkout by Freemius. 14-day money-back guarantee. The free plugin keeps working either way.
If you run one store and this was a one-off, the free version is genuinely all you
need — take it and go. Pro is for people who have been burned by this before, and for
anyone maintaining enough sites that checking each one by hand isn’t realistic.
Common questions
My warning says a different number — 6, 77, 263, 10 million. Does that change anything?
No. The number is how many jobs are waiting, not what went wrong. The same six
causes apply at every size. Only cause 6 depends on the number being genuinely
enormous.
My scheduled actions are pending but never run. Is that the same problem?
Yes — that’s the same thing described from the other side. Past due actions all sit
in the list as pending, because “past due” isn’t a status Action
Scheduler stores. If your scheduled actions are not running and the count keeps
climbing, work through the six causes above: the queue isn’t being processed.
WooCommerce cron isn’t working at all. Where do I start?
With the 60-second test above. Trigger the queue by hand once: if the work happens,
WooCommerce cron is fine and nothing is starting it — cause 1 or 2. If
nothing happens, the jobs themselves are failing — cause 3. Almost every “WooCommerce
cron not working” report resolves to one of those three.
What’s the difference between past-due actions and failed actions?
A past-due action was never attempted — its time came and nothing picked it up.
A failed action was attempted and threw an error. They look similar in the
admin and have opposite fixes: past-due means fix your scheduling, failed means fix
the plugin whose job is breaking. Getting this the wrong way round is the most
common wasted afternoon here.
Can I just delete the past-due actions and move on?
You can, and the warning will come back within days because you removed the
symptom. Worse, those rows are real work — pending subscription renewals and
unsent emails — so deleting them means those things never happen at all.
Will one of the “Action Scheduler cleaner” plugins fix this?
No. Those delete completed actions to shrink your database, which is
useful housekeeping and does nothing for actions that are stuck. If you’re here
because of the past-due warning, a cleaner won’t help.
I don’t use WooCommerce. Why am I seeing this?
Action Scheduler is a shared library that ships inside many plugins — WPForms,
MailPoet, Jetpack, Easy Digital Downloads and others. Any of them can produce this
warning.
The count went down on its own. Am I fine?
Probably a temporary spike — an import, a bulk update, a traffic burst. Check again
in a day. If it climbs back, you have one of the six causes and it just hasn’t
become obvious yet.
Is it safe to run wp-cron.php manually?
Yes. It does exactly what WordPress does on its own schedule — processes whatever
is due right now. It’s the safest first diagnostic there is.