Avg Processing -> Completed Time, WooCommerce

Avg Processing -> Completed Time. The average time WooCommerce orders take to move from processing to completed across the selected period. How to read it, why it matters, and how to act on it.

Metrics type: Supporting Metrics • Category: Ecommerce Platform

Avg Processing -> Completed Time for the selected period.

At a glance

The average fulfilment lead time across your store: how long an order sits in processing (paid, awaiting fulfilment) before it flips to completed. On WooCommerce this is your operational pulse, a rising number means orders are piling up in the warehouse or a fulfilment integration has stalled. The card measures the gap between when each order entered processing and when it reached completed, then averages across all orders that completed in the window.

What it counts	The mean elapsed time, in hours, between an order reaching processing status and reaching completed status, averaged over all orders that hit completed during the selected period.
REST API endpoint	GET /wp-json/wc/v3/orders (filtered to status=completed with date filters for the window). The card reads each order’s status-transition timing, the moment the status meta moved to processing and the moment date_modified reflected the flip to completed, described generally because WooCommerce does not expose a dedicated “time in processing” field.
How the value is computed	For each completed order, the elapsed time is the difference between the timestamp the order’s date_modified recorded when status hit completed and the timestamp it hit processing. These per-order durations are averaged. Orders that skipped processing (for example digital goods auto-completed at checkout) are excluded from the average.
Status treatment	Only the processing -> completed leg is measured. Time spent in pending, on-hold, cancelled, failed, or refunded is not part of this metric. An order that went on-hold -> processing -> completed only counts the processing -> completed portion.
Self-hosted vs managed-Woo	The calculation is identical on self-hosted, WordPress.com, and managed-Woo (Woo.com Cloud, WP Engine, Pressable, Kinsta). Self-hosted stores running fulfilment plugins or a warehouse / 3PL integration drive most of the variance, because the timestamp of the completed flip depends on when that integration calls back.
Time window	30D vsP (default 30D vs the prior 30D)
Alert trigger	>48h, driven by sentiment_key: wc_processing_to_complete_avg
Roles	owner, operations

Calculation

Calculated automatically from your WooCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A self-hosted WooCommerce homewares store on WC 9.0 with a 3PL fulfilment plugin that flips orders to completed when the warehouse confirms despatch. The 30-day window covers 14 May 26 to 12 Jun 26 and 1,200 orders reached completed in that window.

Order cohort	Orders completed	Avg time processing -> completed	Notes
Standard stock items	940	19h	Picked and despatched same or next business day
Made-to-order items	180	71h	Built before despatch, drags the average up
Weekend-placed orders	80	56h	Sat / Sun orders wait for Monday despatch
Digital / auto-complete	(excluded)	n/a	Skipped processing, not in the average
Avg Processing -> Completed Time (this card)	1,200	28.4h	Below the 48h alert threshold

Four things to notice:

1. The store-wide average is 28.4h, under the >48h alert. Nerve Centre stays quiet, but the spread is the real story: standard stock clears in 19h while made-to-order drags to 71h. A single blended number hides product-mix effects, so read it alongside the cohorts when you can.
2. Weekend orders inflate the figure mechanically. Orders placed Saturday and Sunday cannot despatch until Monday, adding ~48h of wall-clock time with no operational fault. A store that runs a heavy weekend-promo calendar will see this card rise every Monday. That is expected, not a regression.
3. The metric depends on when completed is set, not when the parcel physically ships. If the 3PL plugin batches its callback overnight, every order’s completed flip lands at 02:00 regardless of actual despatch time, compressing or stretching the measured duration. Knowing how your fulfilment integration sets completed is essential to reading this card.
4. A breach of 48h is an operations signal, not an accounting one. When this card crosses the threshold the next stop is Order Processing Backlog to see how many orders are stuck in processing right now, and On-Hold Orders to rule out payment-side delays feeding the queue.

Sibling cards merchants should reference together

Card	Why pair it with Avg Processing -> Completed Time
WC Order Processing Backlog	The live count of orders stuck in processing. A rising average and a rising backlog together confirm a fulfilment bottleneck.
WC On-Hold Orders	Payment-pending orders that have not yet entered processing. Rules out a payment-side cause when fulfilment time climbs.
WC Orders by Status	The full status distribution. Shows whether orders are bunching in processing versus clearing through to completed.
WC Total Orders	Volume context. A spike in orders that outpaces warehouse capacity is the most common reason this average climbs.
WC Cancellation Rate	Slow fulfilment drives customer-initiated cancellations. A rising average here often precedes a rising cancellation rate.

Reconciling against WooCommerce

Where to look in WooCommerce Admin:

WP Admin → WooCommerce → Orders filtered to Completed, then open individual orders and read the Order notes sidebar, which timestamps each status transition (for example “Order status changed from Processing to Completed”). There is no first-party report that averages this duration, so the order-notes timeline is the manual reconciliation path.

Other WP Admin views that touch the same data:

• WP Admin → WooCommerce → Status → Logs: fulfilment and gateway plugins often log status transitions here with timestamps.
• WP Admin → Analytics → Orders (WC 4.0+): shows order counts by status over time, useful for confirming how many orders completed in the window even though it does not show the duration.
• Your fulfilment / 3PL plugin’s own dashboard: the system that flips orders to completed usually has its own despatch-time report, which is the true operational source.

Why our number may legitimately differ from WP Admin:

Reason	Direction of divergence
Time-zone. WooCommerce order notes timestamp transitions in the WP site timezone (Settings → General → Timezone); Vortex IQ computes durations in UTC. A duration is a difference of two timestamps, so the offset largely cancels, but a daylight-saving boundary inside the window can shift an order’s duration by an hour.	Marginal; +/- 1h around DST boundaries
Self-hosted uptime / sync lag. If the host was unreachable when an order flipped to completed, the indexer records the transition at the next successful poll, which can stretch the measured duration for that order.	Ours occasionally higher; self-resolves at next clean sync
Plugin-set the completed flip in a batch. A 3PL or fulfilment plugin that batches its “mark completed” callback overnight makes every order in the batch read the same completed timestamp, distorting individual durations. WC order notes show the same batched timestamp, so the two agree, but neither reflects physical despatch time.	Both views reflect the batch timestamp, not real despatch
HPOS vs legacy storage. On High-Performance Order Storage the transition timestamps live in the orders table rather than post-meta. The values are the same, but a store mid-migration can have transitions split across both stores; reconcile against the live WooCommerce → Orders screen.	Either; investigate per-merchant if persistent
Orders that skipped processing. Digital goods auto-completed at checkout never entered processing, so they are excluded here. A manual count in WP Admin that includes them will read a different average.	Ours excludes auto-completed orders

Known limitations / merchant FAQs

Does this measure when the parcel actually shipped? No. It measures when the order’s status flipped from processing to completed. Whether that flip means “despatched”, “delivered”, or “warehouse confirmed pick” depends entirely on how your fulfilment integration sets the completed status. Check your 3PL or shipping plugin’s configuration to know what completed represents on your store before reading this card as a despatch-time SLA.

Why is my average so high when most orders ship same-day? A long tail of slow orders (made-to-order items, back-ordered lines, weekend orders waiting for Monday despatch) pulls the mean up. A blended average is sensitive to outliers. If most orders clear fast but the average looks high, the slow cohort is the place to investigate, not the typical order.

Orders placed at the weekend always spike this number, is that a problem? Usually not. Orders placed Saturday and Sunday cannot despatch until your warehouse reopens, adding wall-clock hours with no operational fault. Expect this card to rise every Monday on a store that takes weekend orders. Judge it against your own weekday baseline rather than a single absolute threshold.

Why does the card exclude some orders? Orders that never entered processing, typically digital goods auto-completed at checkout, have no processing -> completed leg to measure, so they are left out of the average. This keeps the metric focused on physical fulfilment lead time rather than instant digital delivery.

My fulfilment plugin marks orders completed overnight in a batch, does that skew the card? Yes, and it is worth knowing. If the plugin sets completed in a single nightly batch, every order in that batch reads the same completed timestamp, which compresses or stretches the measured duration relative to real despatch time. The number is still a consistent internal signal, but it tracks your plugin’s callback schedule, not the physical warehouse clock.

How often does it refresh? The card refreshes on the standard data sync (typically hourly for self-hosted stores). Because it averages over a 30-day window, the figure is stable; a single recent order will not move it much. For a near-live operational view of what is stuck right now, pair it with Order Processing Backlog.

---

Tracked live in Vortex IQ Nerve Centre

Avg Processing -> Completed Time is one of hundreds of KPI pulses Vortex IQ tracks across WooCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.