WooCommerce explains that checkout-draft orders are temporary and cleanup runs in the background. When drafts accumulate, teams often delete rows directly or install another cleanup plugin before proving whether WP-Cron, Action Scheduler, loopback requests, a failed hook, database locks, or a custom extension caused the backlog. The repair follows one old draft from creation through the expected cleanup system, then uses a small reversible batch only after the scheduler works again.
Use this when WooCommerce checkout-draft counts keep growing, old drafts remain beyond the expected window, scheduled actions are overdue, or cleanup works only after someone visits wp-admin.
Quick answer
Record draft count and age buckets, then inspect WooCommerce Status and Scheduled Actions for overdue or failed work at the same timestamps. Verify WP-Cron or the replacement server cron, loopback requests, Action Scheduler runner, database health, and relevant logs. Repair the trigger first. Re-run one failed or due action on staging, observe a small canary batch, and reconcile order counts, sessions, stock, analytics, and logs before any broader cleanup.
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 |
|---|
| Trigger | WP-Cron or server cron | Runs on schedule |
| Queue | Due and failed actions | Backlog decreases |
| Canary | One old draft | Removed as expected |
| Business state | Orders, stock, analytics | No valid data lost |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Measure draft age and queue health | Count checkout-draft orders by age without exposing customer data and record the oldest ID, creation source, HPOS state, and database growth. | WP-Cron or the replacement trigger runs at its documented interval. |
| Trace cron and scheduled actions | Inspect WooCommerce Status, Scheduled Actions, WP-Cron, server cron, loopback, Action Scheduler logs, failed actions, time zone, and recent plugin changes. | Overdue and failed scheduled actions return to a normal baseline. |
| Reproduce one failed stage | Choose one overdue action and one known draft fixture, reproduce on staging, and identify whether the trigger, claim, callback, query, or delete phase fails. | The canary draft and next automatic batch clean up without removing submitted orders. |
| Repair the runner and canary cleanup | Repair cron, loopback, resource, database, or extension behavior before running a bounded canary cleanup with a verified backup. | Stock, sessions, analytics, logs, webhooks, and HPOS counts remain consistent. |
What to check first
- Count checkout-draft orders by age without exposing customer data and record the oldest ID, creation source, HPOS state, and database growth.
- Inspect WooCommerce Status, Scheduled Actions, WP-Cron, server cron, loopback, Action Scheduler logs, failed actions, time zone, and recent plugin changes.
- Choose one overdue action and one known draft fixture, reproduce on staging, and identify whether the trigger, claim, callback, query, or delete phase fails.
- Repair cron, loopback, resource, database, or extension behavior before running a bounded canary cleanup with a verified backup.
- Reconcile remaining drafts, cart sessions, submitted orders, stock, analytics, webhooks, and scheduled-action health through the next automatic run.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp cron test
wp cron event list --fields=hook,next_run_gmt,next_run_relative | head -n 40
# Review WooCommerce > Status > Scheduled Actions
# Search due and failed work near the oldest checkout-draft timestamp.
Why this usually happens
- DISABLE_WP_CRON is set without a reliable server-level replacement.
- A CDN, WAF, TLS, DNS, or IPv6 route blocks the self-request that advances background work.
- Action Scheduler repeatedly fails and pauses while the dashboard shows only the growing order count.
- Direct deletion bypasses application APIs, logs, HPOS behavior, and downstream reconciliation.
Decision rule
Do not use direct SQL deletion as the first fix. The scheduler must complete a controlled canary and the next automatic run before backlog cleanup is considered stable.
Production verification checklist
- WP-Cron or the replacement trigger runs at its documented interval.
- Overdue and failed scheduled actions return to a normal baseline.
- The canary draft and next automatic batch clean up without removing submitted orders.
- Stock, sessions, analytics, logs, webhooks, and HPOS counts remain consistent.
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.
- Measure draft age and queue health
- Trace cron and scheduled actions
- Reproduce one failed stage
- Repair the runner and canary cleanup
- Verify the next automatic cycle
Mistakes to avoid
- Changing production configuration before recording the exact version, failing request, timestamp, and rollback point.
- Treating a clean dashboard or one successful request as proof while the public page, background job, log, stored record, and downstream system remain unchecked.
- Testing a different role, device, locale, order state, form, cache state, or integration path from the one that users actually reach.
- Leaving debug logging, temporary exclusions, duplicate hooks, helper code, test endpoints, or broad permissions active after the verification window.
Questions teams ask during testing
Can I make this change directly in production?
Start with read-only evidence and use staging for code, update, security, checkout, form, or queue changes. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, role, URL, device, locale, cache state, and downstream integration. Compare stored evidence rather than relying on a visual impression.
What evidence should I retain?
Keep UTC time, exact versions, URL or record ID, expected and actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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, have HandL WP repair the WooCommerce background queue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references