> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # 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. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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](/nerve-centre/kpi-cards/woocommerce/order-processing-backlog) to see how many orders are stuck in `processing` right now, and [On-Hold Orders](/nerve-centre/kpi-cards/woocommerce/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](/nerve-centre/kpi-cards/woocommerce/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](/nerve-centre/kpi-cards/woocommerce/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](/nerve-centre/kpi-cards/woocommerce/orders-by-status) | The full status distribution. Shows whether orders are bunching in `processing` versus clearing through to `completed`. | | [WC Total Orders](/nerve-centre/kpi-cards/woocommerce/total-orders) | Volume context. A spike in orders that outpaces warehouse capacity is the most common reason this average climbs. | | [WC Cancellation Rate](/nerve-centre/kpi-cards/woocommerce/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](/wp-admin/admin.php?page=wc-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](/nerve-centre/kpi-cards/woocommerce/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.