WooCommerce Analytics Not Working? Fix Stalled Reports and Missing Orders

WooCommerce Analytics not working is nearly always a stalled Action Scheduler queue rather than a broken report. Analytics reads pre-aggregated lookup tables that background jobs fill, so when the queue stops, the numbers freeze. Check WooCommerce → Status → Scheduled Actions for pending and past-due actions first, then re-run the historical import from Analytics → Settings.

Analytics is not a live query against your orders table. It is a reporting layer built on aggregate tables that a background queue writes into, which is why it can be wrong in ways the Orders screen never is. Nearly every "Analytics is broken" ticket resolves to one of seven causes, and they are not equally likely.

Fast diagnostic checklist

Start at the top. The first two rows cover most cases on stores doing real volume.

Cause 1: the Action Scheduler queue has stalled

Analytics data is written by jobs queued in Action Scheduler, the background job library bundled with WooCommerce. Go to WooCommerce → Status → Scheduled Actions, where you can view actions by status, run a pending action, and read the log entries for a specific action to find out why it failed (source). Some past-due actions are normal — "because of how WP Cron works, it is normal to have some past-due actions" — but a backlog older than a day points at a site problem.

The defaults explain why a backlog snowballs on a busy store: Action Scheduler claims a batch of 25 actions, runs one concurrent batch, and processes actions for a maximum of 30 seconds per request (source). If your store generates more jobs per minute than that ceiling clears, the queue only grows. The same page says WP-CLI is the best way to increase processing speed.

Drain it directly:

• wp action-scheduler status — counts by status, the fastest read on how deep the hole is.
• wp action-scheduler run --batch-size=100 — processes the queue outside the web request. Add –group= or –hooks= to target one group, and –force if a runner is already claimed.
• wp action-scheduler action list — inspect individual actions; append –help for the filters your version supports.
• wp action-scheduler clean --batch-size=1000 --status=complete — a table with millions of completed rows makes every queue claim slow. Cleaning is part of the fix, not housekeeping.

Those flags are the ones listed in the Action Scheduler WP-CLI reference. If actions are failing rather than queuing, read the action's log entries before re-running anything — a fatal error in a hooked callback fails the same batch forever.

Cause 2: the historical import never finished

New orders are queued for processing automatically; older ones are not. If reports start abruptly at a date, or a migrated store shows nothing before cutover, the import is the culprit. Go to Analytics → Settings and scroll to Import Historical Data. Pick a date period or import everything, and leave "skip previously imported" checked so overlapping ranges do not reprocess. It runs in the background, so you can navigate away (source).

An import that appears stuck at a number is usually queued behind cause 1. Run the queue from WP-CLI and watch the counter move. If it still does not, delete the imported analytics data from the same screen — that removes aggregates, not orders or customers — and start again from a clean state.

Cause 3: WP-Cron is disabled, throttled, or never fires

WP-Cron piggybacks on page loads. Behind a full-page cache or a CDN, most requests never reach PHP, so the scheduler rarely spawns. Diagnose with wp cron test, which checks whether DISABLE_WP_CRON is set, warns on ALTERNATE_WP_CRON, and attempts a real spawn over HTTP (source). Then list what is overdue with wp cron event list and force a pass with wp cron event run --due-now.

The durable fix is to stop depending on traffic. Add define( 'DISABLE_WP_CRON', true ); to wp-config.php and call the scheduler from the system task scheduler instead (source). Every minute is right for a store; hourly is not, because gateway callbacks, stock sync, and analytics share that queue.

Cause 4: caching is serving you stale reports

Two different caches cause this. The first is WooCommerce's own analytics cache: WooCommerce → Status → Tools has a Clear Analytics Cache tool described as "Reset WooCommerce Analytics cache", alongside WooCommerce Transients, Product Lookup Tables, and Fix Analytics Full Refund Data (source). You can run these from the command line too: wp wc tool list --user=1 prints every tool with its identifier, and wp wc tool run <tool_id> --user=1 executes one (source).

The second is your page cache. WooCommerce's guidance is to keep Cart, Checkout, and My Account out of the cache and to exclude the WooCommerce session cookies (source). Extend that to /wp-admin and the REST namespace the reports call: Analytics fetches over REST, and anything caching those responses hands you yesterday's numbers with no error anywhere. A stale object cache does the same — flush it before concluding the data is wrong.

Cause 5: statuses, date range, date type, and timezone

This is the most common false alarm, and the reason "Analytics is not showing all orders" often is not a bug. By default, Pending payment, Cancelled, and Failed are excluded from totals while Processing, On hold, and Completed are included; the default range is Month to Date; and Date Type keys reports off Date created, Date paid, or Date completed, defaulting to Date paid (source). All three are in Analytics → Settings.

A store that fulfils on Date completed but reports on Date paid will disagree with its own finance export every month, and neither number is wrong. Set the store timezone under Settings → General first — a site on UTC while the team thinks in local time shifts a slice of every evening's orders into the next day. After changing excluded statuses, re-import that range.

Cause 6: HPOS sync state and pending database updates

If reports went strange around a storage change, check order storage. High-Performance Order Storage moves orders out of the post tables into dedicated tables, and compatibility mode keeps the two in sync; the setting is at WooCommerce → Settings → Advanced → Features (source). Sync runs in scheduled batches, so it shares the queue that just stalled.

Use the documented commands: wp wc hpos status for an overview, wp wc hpos count_unmigrated for orders pending sync, wp wc hpos sync to move them, and wp wc hpos verify_data to compare the datastores (source). The older wp wc cot namespace is deprecated. Then run wp wc update to apply pending database upgrades — safer than the admin notice on a store large enough to time out a web request (source).

How to stop it recurring

Every cause above is detectable before a person notices. Four habits close the loop:

1. Alert on queue depth, not on errors. A stalled queue throws no error. Track pending and past-due counts, and alert when past-due actions age past an hour.
2. Run the queue from cron, not from traffic. A per-minute system cron plus a WP-CLI runner for backlogs removes the dependency on cache-missing pageviews.
3. Clean the actions table on a schedule. Completed and failed rows reach the millions on a busy store and slow every subsequent claim.
4. Update plugins on staging first. Most analytics regressions arrive with a plugin that registers a failing hook; staging with production-shaped data catches the failing batch first.

How Urumi handles this

A stalled queue is a silent failure: the store keeps taking orders while reporting drifts, and it usually surfaces when someone asks why yesterday looks empty. Platform-level monitoring closes that gap. On Urumi the managed APM covers the background queue alongside web requests, so a growing past-due backlog, a failing action hook, or an import that stopped mid-run raises an alert before anyone opens a report. Revenue AI watches checkout, cart, pricing, and payments around the clock, prices every regression in dollars, and ships the fix as a PR. Grüum ran 1.2M requests a day on Urumi with 0 incidents through peak weeks. Details are on the managed WooCommerce platform page.

Frequently asked questions

Why is WooCommerce Analytics not showing all orders?

Two reasons dominate. Either the orders are in a status excluded from reports — Pending payment, Cancelled, and Failed are excluded by default in Analytics → Settings — or their aggregate rows were never written because the Action Scheduler queue stalled. Check the excluded statuses first, then WooCommerce → Status → Scheduled Actions.

Why is WooCommerce Analytics not updating?

New orders are queued for processing rather than counted instantly, so if the queue is not running, reports stop advancing while the store keeps selling. Run wp cron test to confirm the scheduler spawns, then wp action-scheduler run --batch-size=100 to drain the backlog.

How do I rebuild WooCommerce Analytics data?

Go to Analytics → Settings, use Import Historical Data for the date range you need, and clear the analytics cache from WooCommerce → Status → Tools first. Deleting previously imported analytics data from that screen removes only the aggregates, not your orders or customers.

Does WooCommerce Analytics need Action Scheduler to run?

Yes. The historical import and ongoing order aggregation both queue jobs through Action Scheduler, which by default runs via WP-Cron in batches of 25 actions with a 30-second per-request limit. Without a working scheduler, Analytics cannot populate its lookup tables.

If reports are the symptom but slow admin screens and timeouts are the pattern, the underlying problem is usually capacity rather than configuration — see why WooCommerce slows down under load and AI WooCommerce troubleshooting.

Last reviewed September 2026. Competitor details come from their public pages on the dates linked; check them before you buy.