WooCommerce 11.0 records order IDs that fail during historical Analytics import, shows a warning in Analytics settings, and adds status and retry endpoints. Recovery still needs evidence because a retry can fail again, deleted orders can disappear, and an overflow means the stored list is incomplete.
Use this when WooCommerce Analytics totals do not match order reports, the historical import shows failed orders, the wc-analytics-order-import log contains exceptions, or a migration left missing dates or revenue.
Quick answer
WooCommerce 11.0 Analytics Failed Order Import Retry Runbook should be handled with a narrow evidence-first workflow: capture failed state, read order logs, check status endpoint, then verify the result before making broader changes.
What to check first
- Record the failed count, overflow count, import mode, date window, and WooCommerce version before clicking retry.
- Open WooCommerce Status logs for wc-analytics-order-import and map each failed order ID to its exception and current order state.
- Call the imports status endpoint with an authorized administrator session and preserve the JSON response.
- Retry failed imports once, then inspect wc-admin_import_orders scheduled actions and the log for each order ID.
- Reconcile orders, gross sales, refunds, taxes, shipping, and net sales for the affected period after the queue clears.
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 |
|---|
| Capture failed state | Record the failed count, overflow count, import mode, date window, and WooCommerce version before clicking retry. | The failed count reaches zero or every remaining failure has an owner and recorded cause. |
| Read order logs | Open WooCommerce Status logs for wc-analytics-order-import and map each failed order ID to its exception and current order state. | Scheduled actions finish without recurring exceptions for the same order IDs. |
| Check status endpoint | Call the imports status endpoint with an authorized administrator session and preserve the JSON response. | Analytics date buckets match the agreed order and refund source report. |
| Retry and monitor | Retry failed imports once, then inspect wc-admin_import_orders scheduled actions and the log for each order ID. | An overflow case is handled with a documented full import window and backup. |
Why this usually happens
- A malformed extension field or exception in one order can cause that order to be skipped while the batch continues.
- Older behavior could leave skipped IDs visible only in a log, so the import screen looked complete.
- Deleted orders are pruned during retry and should not be counted as recoverable sales.
- More than one thousand failed IDs can trigger overflow and require a controlled full re-import.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp option get woocommerce_admin_analytics_failed_order_imports --format=json
wp action-scheduler list --hook=wc-admin_import_orders --status=pending
wp wc tool run regenerate_product_lookup_tables --user=1
# Use the documented imports status and retry endpoints with administrator authentication.
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.
- Capture failed state
- Read order logs
- Check status endpoint
- Retry and monitor
- Reconcile analytics
What to tell the client or owner
Send the failed and overflow counts, affected order IDs, log source and timestamps, endpoint response, scheduled-action status, and before-and-after report totals.
Production verification checklist
- The failed count reaches zero or every remaining failure has an owner and recorded cause.
- Scheduled actions finish without recurring exceptions for the same order IDs.
- Analytics date buckets match the agreed order and refund source report.
- An overflow case is handled with a documented full import window and backup.
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, repair WooCommerce analytics imports.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
WooCommerce 11.0 reporting integrity checks
After failed imports are recovered, reconcile the new v3 refund date buckets and run the stable visitor ID session audit so net sales and shopper counts are not distorted by field changes, bot clients, or duplicate identity.
WooCommerce 11.0 recovery and reporting controls
Extend the failed-import runbook with the Checkout Recovery manual-send status matrix and recovery unsubscribe privacy test. For reporting clients, define the sales-report API version contract and audit import status endpoint permissions before delegating diagnostics or retries.
Audit retry generations for orphan work
After starting a retry, run the WooCommerce Analytics failed-import orphan audit to find old jobs, overlapping generations, duplicate rows, stale progress, and totals that do not reconcile.
Helpful references