Alerts for Order Processing Backlog.
At a glance
A live alarm that fires when orders awaiting action build up faster than your team is clearing them. It compares the current count of orders sitting in a pre-fulfilment state against your own 30-day baseline, and escalates when the pile grows beyond twice your normal level. A backlog usually means a warehouse, payment-capture, or staffing bottleneck that will turn into late shipments and customer-service load if left alone.
| What it counts | An alert list keyed off the count of orders in a working-but-not-fulfilled state, primarily processing (paid, awaiting fulfilment) plus pending payment-confirmation orders, measured against the trailing 30-day average for the same state. |
| REST API endpoint | GET /wp-json/wc/v3/orders?status=processing and related status filters. Field used: order status and date_created_gmt. Counts are taken live and compared to the rolling baseline. |
| Trigger logic | Fires when the current backlog exceeds >2x 30D avg pending orders. The baseline is the store’s own trailing 30-day average, so the alert adapts to each merchant’s normal volume rather than a fixed count. A small store and a high-volume store both get a relative trigger. |
| Status treatment | processing is the canonical “paid, needs fulfilment” status and is the core of a backlog. pending (awaiting payment) is included as a leading indicator. on-hold (BACS / cheque awaiting clearance) is a related but distinct signal, see siblings. completed, cancelled, refunded, and failed are not backlog states. |
| HPOS vs legacy storage | Works whether the store uses High-Performance Order Storage (HPOS, the dedicated orders tables) or legacy post-meta storage. The REST API abstracts both, so the count is consistent across storage modes. |
| Polling | The Vortex IQ Woo indexer polls frequently so the backlog count stays near real time. A self-hosted outage can briefly freeze the count until the next successful poll. |
| Self-hosted vs managed-Woo | Identical logic across self-hosted LAMP, WordPress.com Business and Commerce plans, and managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta). The backlog itself is an operations signal, not a hosting one. |
| Time window | RT (real time, compared against a trailing 30-day baseline) |
| Alert trigger | >2x 30D avg pending orders, driven by sentiment_key: wc_alert_order_processing_backlog |
| 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 supplements brand normally ships same-day. Over a bank-holiday weekend the warehouse closes but orders keep flowing. The operations lead gets a Hero alert on the morning of 14 Mar 26.| Date | Orders in processing at 09:00 | 30D avg for that hour | Ratio vs baseline | Alert state |
|---|---|---|---|---|
| 11 Mar 26 (Fri) | 46 | 44 | 1.0x | Quiet |
| 12 Mar 26 (Sat, warehouse closed) | 91 | 45 | 2.0x | FIRING |
| 13 Mar 26 (Sun, warehouse closed) | 148 | 45 | 3.3x | FIRING |
| 14 Mar 26 (Mon, before catch-up) | 162 | 46 | 3.5x | FIRING |
| 14 Mar 26 (Mon, after catch-up shift) | 38 | 46 | 0.8x | Cleared |
- The baseline is the store’s own normal. The trigger is not a fixed number; it is twice this brand’s typical
processingcount. A store that normally carries 5 orders would fire at 11, while this one fires at around 90. The relative baseline is why the same card works for a side hustle and a high-volume seller. - The backlog compounds over a closure. Each day the warehouse was shut, paid orders kept arriving and none cleared, so the pile grew 46 to 91 to 148 to 162. The card fired on the first day it crossed 2x and stayed lit until the catch-up shift drained it. This is exactly the early warning a planned-closure backlog needs.
- It cleared when the work was done, not on a timer. The alert resolved once the live count dropped back under the baseline after Monday’s catch-up shift. The card tracks reality, not a fixed cooldown.
- Pair it with processing time. A persistent backlog drags up Avg Processing to Completed Time. If that sibling is also climbing, customers are now waiting noticeably longer, which is when refund and chargeback risk starts to rise.
Sibling cards merchants should reference together
| Card | Why pair it with Order Processing Backlog |
|---|---|
| WC Avg Processing to Completed Time | The backlog’s downstream effect. A growing pile means each order waits longer, this card measures by how much. |
| WC Orders by Status | The full status breakdown so you can see whether the pile is processing, pending, or on-hold driven. |
| WC On-Hold Orders | A distinct backlog of payment-awaiting orders (BACS, cheque). High on-hold plus high processing points to a payment bottleneck on top of a fulfilment one. |
| WC Total Orders | Context. A backlog during a genuine sales spike is a happy problem; a backlog on flat orders is a staffing or process failure. |
| WC Cancellation Rate | If the backlog persists, customers start cancelling. A backlog that bleeds into rising cancellations is costing real revenue. |
Reconciling against WooCommerce
Where to look in WooCommerce Admin: WP Admin → WooCommerce → Orders and click the Processing filter tab to see the live count this card is built on. The number in parentheses next to “Processing” is your current backlog. Switch to Pending payment to see the leading-indicator pile. WooCommerce → Reports → Orders gives a historical view to sanity-check your normal baseline. Other WP Admin views that relate to this alert:- Orders screen status tabs (Processing, Pending payment, On hold): the parenthetical counts are the raw inputs. Add Processing plus Pending for the closest match to the backlog this card watches.
- WooCommerce → Home → Stats: shows orders that need attention but uses the Analytics module’s framing, which can differ slightly.
- A fulfilment plugin’s dashboard (ShipStation, Order Desk): these often define “awaiting fulfilment” differently and may exclude on-hold orders.
| Reason | Direction of divergence |
|---|---|
| Baseline comparison. This card alerts on a ratio to your 30-day average; WP Admin shows only the current raw count. The Admin count and our raw count should match, but the alert is a relative judgement on top. | Different framing |
| Timezone. Order timestamps use WP site timezone; this card’s baseline windows are computed in UTC. Day-boundary orders may fall on different sides. | +/- around midnight |
Status inclusion. We weight processing as the core and include pending as a leading signal; a fulfilment plugin may count only processing. | Ours can read higher if pending is large |
| Self-hosted sync lag. If the host was unreachable during a poll, the live count freezes until the next successful sync. | Ours temporarily stale; self-resolves |
Auto-complete plugins. Some stores auto-flip digital orders straight to completed, so they never enter the backlog. | Ours lower than a store that holds everything in processing |
Known limitations / merchant FAQs
Why does it compare against my own average instead of a fixed number? Because a “backlog” means something different for every store. Forty pending orders is a crisis for a one-person operation and a quiet Tuesday for a high-volume seller. Triggering at twice your own trailing 30-day average means the alert is meaningful whatever your scale, and it adapts automatically as your business grows. Will a genuine sales spike fire this even though nothing is wrong? Yes, and that is often useful. A flash sale or a viral moment that doubles yourprocessing pile will fire the card, which is a prompt to staff up fulfilment before shipments slip. Read it alongside Total Orders: a backlog driven by a real order spike is a capacity prompt, not a process failure.
Does it include on-hold orders?
Not as the core signal. The backlog is built on processing (paid, needs fulfilment) with pending as a leading indicator. on-hold is a separate payment-awaiting pile tracked by On-Hold Orders. Watch both during a payment-method problem.
My store auto-completes orders, so I never see a backlog, is that a problem?
If you auto-flip orders straight to completed (common for digital goods or some subscription setups), they never sit in processing and this card stays quiet by design. That is correct behaviour for fully automated fulfilment. The card is most useful for stores with a physical pick-pack-ship step.
The alert cleared but my warehouse is still behind, why?
The card watches order status, not physical reality. If your team marks orders completed before they actually ship, the backlog clears in WooCommerce while parcels still sit on the dock. The fix is process discipline: only mark completed when the parcel is genuinely dispatched, so the card reflects the truth.
Why did the count freeze for a few hours?
Most likely a self-hosted host was unreachable during a poll, so the live count went stale until the next successful sync. Check WooCommerce → Settings → Advanced → REST API to confirm the Vortex IQ key is active and your host status page for any outage.