WooCommerce Scheduled Actions Hook Reference

If you’ve copied a Hook name from WooCommerce Scheduled Actions into Google because you’ve no idea what it is, this page is for exactly that.

The Hook is basically the name of the job WooCommerce or a plugin has put into the background queue. Sometimes it is simple housekeeping. Sometimes it is tied to orders, payments, customer data or another service outside your website.

The important bit is not just finding out what the name means. You also need to know what could happen if you run it, cancel it or delete it.

Also remember that a reference like this can tell you what a Hook normally does. It cannot see how your particular shop, plugins or integrations are using it.

If I’m not sure what an action belongs to, I leave it alone until I know.

If you need the basics before using this list, start with WooCommerce Scheduled Actions Explained.

Quick reference

Those labels are only a starting point. A failed low-risk housekeeping job can still cause a performance problem, and a perfectly normal-looking payment or webhook action can matter a lot more than its name suggests.

woocommerce_deliver_webhook_async

Normally belongs to: WooCommerce webhooks and integrations

What it does: Sends a WooCommerce webhook to another system in the background.

A webhook is basically WooCommerce telling another service that something happened. That could be an order being created, a product changing, a customer update or another event an integration is listening for.

WooCommerce normally sends these in the background so the customer does not have to sit waiting while another server responds.

If you see one or two of these pending for a short time, that does not automatically mean anything is wrong.

If you see a growing queue of them, I’d want to know where those webhooks are meant to be going and why they are not clearing.

If it keeps failing: check the webhook itself, its delivery logs, the destination URL and whether the outside service is responding.

Would I run or delete it manually?

Not until I knew exactly which webhook it belonged to.

If you manually run one, you may send the same event to the outside service again. Depending on the integration, that could mean repeating an update outside WooCommerce.

Deleting it can do the opposite. Something that should have been sent might never get there.

This is one I’d be careful with.

woocommerce_cancel_unpaid_orders

Normally belongs to: WooCommerce core

What it does: Looks for old unpaid checkout orders and cancels the ones that have passed the store’s Hold Stock time.

WooCommerce uses this so unpaid orders do not hold stock forever.

This one matters because it changes real orders.

If your Hold Stock setting is 60 minutes, for example, WooCommerce can use this job to find qualifying unpaid orders older than that and cancel them so the reserved stock can be released.

One thing worth knowing is that WooCommerce only schedules this job when stock management is enabled and a Hold Stock time of at least one minute is set.

On current WooCommerce versions, it is aimed at unpaid orders created through the customer checkout, including the normal checkout and Checkout Block. It does not simply cancel every unpaid order sitting in the database regardless of how that order was created.

That is normal when the customer genuinely abandoned checkout.

The problem is when the customer actually paid but WooCommerce never got the message properly.

If a payment gateway, callback or webhook problem has left paid orders sitting in Pending payment, this job can make the situation even more confusing by cancelling them later.

If it keeps failing: I’d check WP-Cron and Action Scheduler, but I’d also check whether unpaid orders are actually being cancelled as expected.

Would I run it manually?

I wouldn’t do that on a live shop without checking the Pending payment orders first.

This is not just housekeeping. It can change order status and affect stock.

woocommerce_cleanup_personal_data

Normally belongs to: WooCommerce privacy and data-retention settings

What it does: Runs WooCommerce’s configured personal-data cleanup.

This is one where the harmless-looking word “cleanup” can be misleading.

WooCommerce lets a store decide how long it keeps things like inactive accounts and personal data attached to pending, failed, cancelled or completed orders.

This Scheduled Action helps apply those rules.

Depending on the settings, WooCommerce can anonymise personal information and move some old orders to the bin.

Before touching this one: check WooCommerce → Settings → Accounts & Privacy and see what data-retention rules are actually configured.

If it keeps failing: the store’s intended privacy cleanup may not be happening.

Would I run or delete it manually?

Not without checking the retention settings first.

This is customer data, and some of the cleanup cannot simply be undone afterwards.

I’d treat this as a higher-risk action even though it is a normal WooCommerce job.

wc-admin_import_orders

Normally belongs to: WooCommerce Analytics

What it does: Moves order information into the data WooCommerce uses for Analytics and reports.

Your actual WooCommerce order and the Analytics report are not exactly the same thing.

WooCommerce can have the real order sitting perfectly happily in the store while its reporting data is behind or wrong.

This Hook is part of the process that keeps those reports up to date.

You may see it when orders are created or updated, and you can also see a lot of activity when WooCommerce is working through historical Analytics data.

If it keeps failing: check whether WooCommerce Analytics is enabled and whether the reports are actually up to date.

I’d also check the WooCommerce version before doing anything drastic. There have been confirmed WooCommerce bugs around this Hook. One affected WooCommerce 9.6, where actions could still be scheduled even when Analytics was disabled.

There have also been real cases where very large wc-admin_import_orders backlogs put heavy load on the database and server.

Would I delete thousands of them because the admin is slow?

No.

I’d first work out why so many are being created and whether Analytics is still trying to process them.

Deleting the queue may make the screen look cleaner while leaving the reporting problem exactly where it was.

wc_update_product_lookup_tables_column

Normally belongs to: WooCommerce core

What it does: Rebuilds individual columns in WooCommerce’s product lookup table.

WooCommerce keeps separate lookup information to make jobs like product filtering, sorting and reporting quicker.

You may see this Hook after WooCommerce starts regenerating the Product lookup tables from WooCommerce → Status → Tools.

Rather than rebuilding everything in one huge job, WooCommerce can process the lookup data in smaller scheduled actions.

On a larger catalogue, that can take a while.

While regeneration is still running, WooCommerce warns that product display, sorting and reports may not be completely accurate.

If it appears stuck: I’d check whether the pending actions are still progressing before assuming it has failed.

Look at:

• whether the oldest pending action is moving
• whether new actions are completing
• WP-Cron
• Action Scheduler
• PHP or database errors
• server resources

Would I clear the queue halfway through?

Not just because it looks big.

If WooCommerce is genuinely rebuilding its lookup data, stopping it halfway through can leave you with incomplete data.

wc_update_product_lookup_tables_rating_count_batch

Normally belongs to: WooCommerce core

What it does: Rebuilds product rating-count information in batches as part of product lookup-table regeneration.

This is related to the lookup-table job above, but it deals specifically with rating-count data.

If you see it during a product lookup-table rebuild, that can be completely normal.

Again, the important thing is whether the queue is moving.

A large catalogue can create plenty of background work without anything actually being broken.

If it keeps failing or never clears: I’d check the same things as the other lookup-table jobs. Cron health, Action Scheduler, PHP/database errors and server limits are all worth looking at.

Would I delete it?

Not while WooCommerce is still trying to regenerate the lookup data.

I’d find out why it is stuck first.

wc_delete_related_product_transients_async

Normally belongs to: Older WooCommerce versions

What it did: Cleared cached information WooCommerce used for related products after product changes.

This is a legacy Hook now, which is worth knowing if you’ve found it while looking through an older queue or an older WooCommerce site.

A transient is temporary cached data. Older WooCommerce versions used this background action to clear related-product cache data when products changed.

WooCommerce 9.8.3 fixed a problem where duplicate copies of this action could be scheduled for the same product.

The related-product transient system involved here was later deprecated from WooCommerce 10.1.0, so this should not be treated as a normal current WooCommerce Hook in the same way as the others on this page.

If I found thousands of these actions, the first thing I’d check is the WooCommerce version and the age of the actions.

You may simply be looking at old Scheduled Actions left behind from a previous WooCommerce version.

If they are recent, I’d want to know what is still creating them before assuming current WooCommerce core is responsible.

Would I panic because I saw 10,000 of them?

No.

I’d first work out when they were created, what WooCommerce version was running at the time and whether they are still being added now.

On an older installation where they are actively being created, I’d also look at anything repeatedly changing products, such as a bulk import, feed plugin, marketplace integration or another process saving large numbers of products.

woocommerce_cleanup_sessions

Normally belongs to: WooCommerce core

What it does: Cleans out expired WooCommerce session data.

Sessions are part of how WooCommerce remembers temporary customer information while somebody moves around the shop, including things connected to their cart.

WooCommerce schedules regular cleanup so expired session data does not sit in the database forever.

Seeing this action normally is nothing I’d worry about.

If it keeps failing: expired session records may start building up over time.

If the session table is getting very large or the site has cart/session problems, then the failed cleanup becomes more interesting.

Would I run it manually?

This is usually lower risk than anything involving payments or orders, but I’d still check why the normal scheduled job is not running first.

The failure is telling you something. I’d rather fix that than make manually running it part of the routine.

woocommerce_cleanup_logs

Normally belongs to: WooCommerce core

What it does: Clears WooCommerce logs that have passed their retention period.

WooCommerce and its extensions can create a lot of log data over time, so old logs need cleaned up.

Normally this is straightforward housekeeping.

There is one thing I’d keep in mind though.

Logs are often what we need when something has gone wrong.

If I’m in the middle of investigating a checkout, payment or integration problem, I would not start manually clearing logs before I’d saved anything useful.

If it keeps failing: old log data can build up and use more storage than it should.

Would I run it manually?

Usually this is fairly low risk if the store’s logging and retention settings are understood.

I just wouldn’t make deleting evidence the first step in a fault investigation.

wc_admin_unsnooze_admin_notes

Normally belongs to: WooCommerce Admin

What it does: Brings snoozed WooCommerce admin notices back when their reminder time is reached.

This one sounds more technical than it really is.

WooCommerce lets some dashboard notices be snoozed. This action helps bring them back later when they are due.

If it fails, it normally means an admin reminder might not reappear when expected.

It is not processing a customer payment or changing an order.

Would I worry about seeing it?

Normally, no.

If this is the only failed action on an otherwise healthy shop, it is a very different situation from a queue full of payment or webhook failures.

I would still check why it failed, but it would be low on my list of things likely to be hurting customers.

A related Hook you may see: action_scheduler_run_queue

This one is slightly different.

You may see action_scheduler_run_queue in Site Health, WP Crontrol or server logs while you’re trying to work out why Scheduled Actions aren’t moving.

It is basically the runner that keeps Action Scheduler moving.

Action Scheduler's default runner is tied into WP-Cron and normally tries to start processing about once a minute. Depending on the version and tool you're looking at, you may see the scheduled event as action_scheduler_run_schedule and the runner action as action_scheduler_run_queue.

So if hundreds of normal jobs are becoming past-due, this is one of the things worth checking.

If action_scheduler_run_queue itself is not firing properly, the jobs behind it can start stacking up even though there is nothing wrong with each individual Hook.

I would not delete it simply because you see it running every minute.

Action Scheduler is used by WooCommerce and plenty of other WordPress plugins. Removing the runner without understanding what relies on it can stop background work across more than one plugin.

Why I don’t give a simple “safe to delete” answer

I could put a green tick or red cross beside every Hook on this page, but I don’t think that would be very responsible.

Take woocommerce_deliver_webhook_async.

On one shop it could be sending fairly unimportant information to an outside service.

On another it could be part of the process connecting orders to stock, accounting or fulfilment.

It is the same Hook name.

The same applies to failures.

One failed housekeeping action from six months ago is not the same thing as the same payment-related action failing every five minutes today.

Use the Hook name to work out what you’re looking at.

Then check:

1. who created it
2. what its arguments contain
3. what the Group says
4. what the log says
5. whether the related part of the shop is actually working
6. whether the action is still being created
7. whether the queue is growing or clearing

That’s usually enough to tell you whether you’re looking at normal background noise or something that actually needs fixed.

Can’t find your Hook?

This reference will grow as we come across more real WooCommerce Scheduled Actions.

If the Hook you’re looking at is not listed yet, don’t assume that means it is safe to remove.

Check the Hook name, Group, arguments and log. If there is a plugin prefix in the name, that is often a good place to start.

And if you’re still not sure what it is doing, I’d leave it alone on a live shop until you know.

If you have a Scheduled Actions problem and don’t want to experiment on a live WooCommerce store, we can take a look at it through our Online Shop / WooCommerce service or Website Fixes service.