Avg Processing -> Completed Time for the selected period.
At a glance
The average fulfilment lead time across your store: how long an order sits inprocessing(paid, awaiting fulfilment) before it flips tocompleted. 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 enteredprocessingand when it reachedcompleted, 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 tocompleted 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 |
- The store-wide average is 28.4h, under the
>48halert. 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. - 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.
- The metric depends on when
completedis set, not when the parcel physically ships. If the 3PL plugin batches its callback overnight, every order’scompletedflip lands at 02:00 regardless of actual despatch time, compressing or stretching the measured duration. Knowing how your fulfilment integration setscompletedis essential to reading this card. - 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
processingright 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 toCompleted, 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
completedusually has its own despatch-time report, which is the true operational source.
| 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 fromprocessing 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.