WooCommerce

Action Scheduler 4 Queue Index Performance Audit

HandL WP Engineering·Jul 3, 2026

Action Scheduler tables can become a hidden performance problem on WooCommerce sites with emails, subscriptions, webhooks, imports, and CRM jobs. With Action Scheduler 4 changing cleanup behavior, teams should record table size, hook distribution, indexes, slow queries, and retry outcomes before and after update.

Use this for WooCommerce stores with large `wp_actionscheduler_*` tables, slow admin screens, stuck emails, delayed webhooks, or background jobs that fall behind during traffic spikes.

Quick answer

Action Scheduler 4 Queue Index Performance Audit should be handled with a narrow evidence-first workflow: measure queue tables, group by hook, check indexes, then verify the result before making broader changes.

What to check first

Measure action and log table size, row count, and oldest pending or failed action.
Group actions by hook, status, claim, and extension owner.
Check database indexes and slow query logs before changing retention or cleanup behavior.
Export critical failed actions before old failures are cleaned automatically.
Retest email, payment, webhook, subscription, and CRM jobs after update.

Diagnostic table

Use this table to keep the work practical. It connects the symptom to evidence and a verification step.

Action	Evidence to collect	How to verify
Measure queue tables	Measure action and log table size, row count, and oldest pending or failed action.	Queue row counts and table sizes are recorded before and after cleanup.
Group by hook	Group actions by hook, status, claim, and extension owner.	High-volume hooks have an owner and expected retry behavior.
Check indexes	Check database indexes and slow query logs before changing retention or cleanup behavior.	Slow query evidence improves without hiding active failures.
Export failures	Export critical failed actions before old failures are cleaned automatically.	Business-critical jobs still complete after the Action Scheduler change.

Why this usually happens

Background jobs can grow for months without a visible checkout error.
Failed actions can be harmless noise or real lost business events.
Large log tables slow admin reports and scheduled cleanup tasks.
A cleanup policy can reduce table size while also removing evidence support needed.

Field notes

Group by hook before blaming the database. The hook usually reveals the responsible extension.
Export failure samples before changing cleanup windows.
Measure query time on staging with production-like row counts when possible.

Useful command or data shape

Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.

wp action-scheduler list --status=pending --format=count
wp action-scheduler list --status=failed --fields=hook,status,scheduled_date_gmt,args --format=csv > failed-actions.csv
wp db query "select hook,status,count(*) rows_count from wp_actionscheduler_actions group by hook,status order by rows_count desc limit 25;"
wp db query "show index from wp_actionscheduler_actions;"

Safe fix order

Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.

Measure queue tables
Group by hook
Check indexes
Export failures
Retest jobs

What to tell the client or owner

Give the site owner a short queue report: noisy hooks, critical failures, cleanup setting, database impact, and which jobs were retested.

Production verification checklist

Queue row counts and table sizes are recorded before and after cleanup.
High-volume hooks have an owner and expected retry behavior.
Slow query evidence improves without hiding active failures.
Business-critical jobs still complete after the Action Scheduler change.

Mistakes to avoid

Do not judge the fix by one browser or the homepage only.
Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
Do not add a cache, security, or tracking plugin while the original problem is still unclear.
Do not leave test users, temporary debug logs, or broad API keys active after verification.

When HandL WP should help

Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.

If this is active on a production site, audit WooCommerce queue performance.

Related HandL WP guides

Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.

Helpful references

WooCommerce Action Scheduler Performance