WooCommerce 11.0 includes Action Scheduler 4. A version check alone cannot show whether a production queue still drains, claims actions correctly, retains useful history, and completes payment, webhook, email, subscription, analytics, and stock jobs within business thresholds.
Use this for stores with subscriptions, memberships, webhooks, imports, feeds, CRM sync, high order volume, scheduled email, or a history of WP-Cron backlogs.
Quick answer
Capture a seven-day queue baseline before updating, including pending, overdue, in-progress, failed, completion latency, runner source, and top hooks. Repeat with production-sized staging data after WooCommerce 11.0, trigger representative business jobs, pause a runner to prove recovery, and release only when queue health and downstream results match the baseline.
What to check first
- Capture queue counts, oldest pending age, completion latency, failed rate, top hooks, claims, and runner sources before upgrade.
- Confirm table health, expected indexes, disk capacity, object cache behavior, WP-Cron, and any system cron runner.
- Run payment, email, webhook, subscription, inventory, import, and analytics fixtures on production-sized staging.
- Pause one runner long enough to build a small backlog, restore it, and measure drain and retry behavior.
- Set alerts for oldest pending age, failure rate, repeated hook failures, and business jobs beyond their service level.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Normal load | Representative order and integration jobs | Backlog and completion latency remain near baseline |
| Runner pause | Pause WP-Cron or the dedicated runner briefly | Backlog is visible and drains after recovery |
| Permanent failure | Synthetic job with invalid non-sensitive input | Failure is retained with enough evidence for an owner |
| Duplicate trigger | Submit the same idempotent fixture twice | Business side effect occurs once or follows documented rules |
Decision rule
Hold the upgrade when the oldest pending age grows, critical hooks fail or repeat, a paused backlog does not drain, claims remain stuck, or the team cannot connect a failed action to a business owner.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Capture the queue baseline
- Verify storage and runners
- Run business fixtures
- Prove backlog recovery
- Add owner-level alerts
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture the queue baseline | Capture queue counts, oldest pending age, completion latency, failed rate, top hooks, claims, and runner sources before upgrade. | Queue counts and completion latency return to the approved range. |
| Verify storage and runners | Confirm table health, expected indexes, disk capacity, object cache behavior, WP-Cron, and any system cron runner. | Payment, webhook, email, stock, and subscription fixtures complete once. |
| Run business fixtures | Run payment, email, webhook, subscription, inventory, import, and analytics fixtures on production-sized staging. | A deliberate short backlog drains after the runner returns. |
| Prove backlog recovery | Pause one runner long enough to build a small backlog, restore it, and measure drain and retry behavior. | Failed actions retain a useful hook, timestamp, error, and owner path. |
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 status
wp action-scheduler action list --status=pending --per-page=20
wp action-scheduler action list --status=failed --per-page=20
wp cron event list --fields=hook,next_run_relative,recurrence
# Record oldest pending age and top failing hook before changing state.
Production verification checklist
- Queue counts and completion latency return to the approved range.
- Payment, webhook, email, stock, and subscription fixtures complete once.
- A deliberate short backlog drains after the runner returns.
- Failed actions retain a useful hook, timestamp, error, and owner path.
Why this usually happens
- A queue can be healthy overall while one high-value hook remains overdue.
- WP-Cron traffic dependence can hide runner starvation on low-traffic or heavily cached sites.
- Bundled library upgrades can expose extension assumptions about storage, claims, logging, or retention.
Field notes
- Separate synthetic fixture groups from production hooks.
- Store counts and ages, not customer payloads, in monitoring.
- Compare the same traffic, data volume, and runner configuration across versions.
Mistakes to avoid
- Do not judge queue health from the total pending count alone.
- Do not delete failed actions before recording the hook and error.
- Do not test only manually triggered cron.
- Do not run a destructive failure fixture against live customer jobs.
What to tell the client or owner
Provide Action Scheduler version, queue counts, oldest age, runner source, top hooks, claim state, failed action ID, error, related business event, database size, and recovery time.
Questions teams ask during testing
What is the most useful queue metric?
Oldest pending age by business-critical hook is often more actionable than a single total count.
Should every failed action be retried?
No. Retry temporary failures, but correct permanent input or code errors before replaying them.
Why pause a runner?
A controlled staging pause proves that monitoring detects backlog and that recovery drains it safely.
When HandL WP should help
HandL WP can baseline Action Scheduler, inspect storage and cron, build business fixtures, reproduce runner starvation, correct hook failures, and configure useful queue alerts.
If this is active on a production site, audit a WooCommerce background queue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references