WooCommerce Action Scheduler Table Missing: Identify the Migration Failure

An error saying an actionscheduler_actions table does not exist is a storage failure, not simply an overdue queue. The application attempted to access a table that its database connection could not find. Before creating anything, establish which database, site prefix, Action Scheduler version, and storage implementation the running site actually uses.

A migration or incomplete restore is one possible cause, not a conclusion supplied by the message. Preserve the error and database evidence. Do not drop queue tables, paste a schema from another site, or rerun purchase and renewal actions as a default recovery step.

Quick triage: what is actually missing?

1. Capture the error and the change that preceded it

Record the exact error text, timestamp, operation, and first relevant stack frames. Did it occur during plugin activation, checkout, a background request, or opening Scheduled Actions? Note the last WooCommerce update, hosting move, database restore, prefix change, or PHP switch.

A message ending in class-wpdb.php identifies WordPress’s database layer, not necessarily the component that caused the missing schema. Follow the caller. Our Action Scheduler ownership guide helps when hook and callback evidence is available, but a storage failure can occur before an individual action is even loaded.

Keep a recoverable database and file snapshot before any repair. For a live store, restoring an old database can discard new orders and payment records. Recovery must account for activity since the backup, not just whether the SQL import completes.

2. Resolve the database and prefix before comparing tables

wp_actionscheduler_actions is a common example, not a universal table name. A site using shop_ may use shop_actionscheduler_actions. Multisite adds site-specific context. A database-qualified error can include both database and table names; do not mistake that combined string for the table identifier.

An authorized administrator can inspect the following from the correct installation. On multisite, select the intended site using --url. Treat all output as private until reviewed.

wp db prefix
wp db query 'SELECT DATABASE();'
wp db query 'SHOW TABLES;'
wp plugin list --fields=name,status,version --format=table

These are inspection commands, not schema repairs. The table list can be large, so compare it locally rather than posting the entire output. WP-CLI may fail while bootstrapping broken plugins; if so, have the host inspect database metadata with approved read-only access instead of repeatedly retrying activation.

Once the exact table is identified, the operator can use SHOW CREATE TABLE for an existing table to inspect its definition. Do not run a copied example against a guessed prefix. Compare the same database connection and site context used by the failing application, especially where reads can be routed to replicas.

3. Identify the active storage generation and library

The official Action Scheduler FAQ distinguishes the generations: before 3.0, actions were stored as a custom post type in WordPress tables; 3.0 and newer use custom tables by default and migrate legacy data. Storage is replaceable, so custom implementations must also be considered.

The usual modern schema includes actions, claims, groups, and logs tables. Their definitions and schema versions belong to the installed release, not a random SQL snippet. A current table definition may differ from an older backup. An Action Scheduler library version and its internal schema versions are related concepts, not interchangeable version numbers.

Several plugins can bundle Action Scheduler. The FAQ explains that the most recent registered library normally loads after plugins have registered their copies. Installing a standalone copy or inspecting only WooCommerce’s bundled folder therefore does not necessarily identify the running library. Ask the developer to confirm its selected version, source path, and actual store class in the failing context.

4. Separate legacy data migration from schema creation

The official version 3.0 migration guidance says migration begins when dependencies are met. By default, migration is initiated from the internal WPPostStore; migration from a custom datastore is not automatically enabled in the same way. It also recommends database backups and comparing action counts before and after migration.

Those details matter because two operations are easy to confuse: preparing a compatible destination schema and transferring legacy actions into it. A missing destination table cannot be repaired merely by increasing queue throughput. Conversely, finding modern tables does not prove that all legacy actions were migrated.

Read logs from the first upgrade or restore attempt. Ask the host to check schema-change permissions, database errors, storage limits, and any replication restrictions. Check whether the backup actually contained all tables for this site. The appropriate correction depends on this evidence; granting broad privileges or forcing migration filters is not a default troubleshooting step.

The WooCommerce Scheduled Actions documentation is useful for locating the admin screen and action history. Its description of post-based storage reflects older behavior; use Action Scheduler’s storage documentation and your installed implementation for schema decisions.

What public cases demonstrate—and what they do not

In this WordPress.org missing-table case, the reporter asked about MySQL group replication. Support linked the table-creation code and requested more evidence; the thread did not establish a universal repair. A separate WP Mail SMTP activation case reports a missing Action Scheduler table without WooCommerce being the only possible library consumer.

These cases support investigating database topology and the calling plugin. Their forum status labels are not evidence that manually creating a table or reactivating a plugin is safe on your store.

5. Repair through a version-matched recovery plan

Give the responsible developer the sanitized error, selected library version, database/prefix comparison, schema inventory, and backup timeline. Rehearse the maintainer-supported initialization, migration recovery, or restoration procedure on a protected clone. Disable real payments, customer emails, and external callbacks on that clone before allowing queue processing.

Do not automatically downgrade after a storage migration: the migration guidance explicitly warns that reverting requires restoring a backup. For production, agree how new orders and externally completed operations will be reconciled. A restored pending renewal may correspond to a charge that already succeeded elsewhere.

Verify storage first, processing second, business outcomes third. Confirm the expected tables and installed schema are accessible, the original error stops, and representative action history remains available. Compare counts with the pre-change inventory, allowing for legitimate completions. Then observe normal processing of an approved low-risk task. Renewals, purchases, and customer notifications require application-level checks before any replay.

FAQ

Will enabling WP-Cron recreate the missing table?

Not by itself. WP-Cron can trigger processing, but it is distinct from Action Scheduler storage. Use our execution-gate guide only after the storage problem is understood.

Should I clear all failed actions afterward?

No. Preserve history and inspect representative failures. Our failed-action guide explains how hook errors differ from storage failures.

Can Queue Health fix the schema?

No. Queue Health provides read-only queue and runner signals when the required data is accessible. It does not create tables, restore lost jobs, rerun tasks, or guarantee payment reconciliation.