> ## 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. # Order Processing Backlog, OpenCart > Real-time alert that fires when orders awaiting processing pile up beyond your normal rhythm on OpenCart. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Real-time alert that fires when the count of orders stuck awaiting processing exceeds twice your 30-day average, the early warning that fulfilment has stalled. ## At a glance > Backlog is the count of orders sitting in a not-yet-fulfilled status (typically Pending and Processing) that have not progressed to a completed or shipped state. This alert watches that count in real time and fires when it climbs past 2x the trailing 30-day average. A backlog spike is the cleanest single signal that something has broken in your fulfilment flow: a warehouse outage, a stuck payment-capture step, a shipping-extension failure, or simply a demand surge that has outrun your packing capacity. | | | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The live count of orders whose `order_status_id` maps to a pre-fulfilment status (commonly Pending and Processing) and has not advanced to Complete, Shipped, or an equivalent terminal status. | | **Status treatment** | Status names in OpenCart are fully configurable per store via `oc_order_status`. The alert keys on the *configured* pre-fulfilment statuses, not on hard-coded names, so a store that renamed "Processing" to "Picking" is still covered. | | **Refunds** | Refunded and Cancelled orders are excluded from the backlog count, they are no longer awaiting fulfilment. | | **Cancelled orders** | Excluded. A Cancelled order is resolved, not backlogged. | | **Currency** | Not relevant. This is a count of orders, not a money figure, so multi-currency stores are unaffected. | | **Multi-store** | Counts across all `store_id` values by default. A single OpenCart install serving several storefronts aggregates here unless you filter to one store. | | **Time window** | RT (evaluated continuously against the trailing 30-day average) | | **Alert trigger** | Backlog count `> 2x 30-day average` | | **Roles** | owner, operations | ## Calculation Calculated automatically from your OpenCart 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 UK auto-parts store on OpenCart 4.x. The store fulfils from a single warehouse and uses a shipping extension that pushes labels to a courier API. The trailing 30-day average backlog (orders sitting in Pending or Processing at any given hour) is 38 orders. The alert threshold is therefore 76. | Time (14 Mar 26) | Pending | Processing | Backlog total | State | | ---------------- | ------- | ---------- | ------------- | ------------------------- | | 08:00 | 22 | 19 | 41 | Normal | | 11:00 | 31 | 24 | 55 | Normal, busy morning | | 14:00 | 58 | 47 | 105 | **ALERT FIRES** (over 76) | | 17:00 | 71 | 63 | 134 | Still climbing | | Next day 09:00 | 18 | 21 | 39 | Recovered after fix | What's interesting here: 1. **The backlog climbed, but order volume did not.** New orders arrived at a normal rate all afternoon. The pile-up came from the *exit* side: orders stopped leaving Processing because the courier label API started returning errors at around 13:30. The backlog count rose purely because fulfilment stalled, not because demand spiked. 2. **The alert beat the human.** Staff did not notice the courier failures until the end-of-day label run failed wholesale. The alert flagged the abnormal accumulation three and a half hours earlier, when the count crossed 76. 3. **The 2x-average threshold absorbed the busy morning.** The 55-order late-morning peak was a genuinely busy day, not a fault, and it stayed under the threshold. A fixed numeric trigger would have cried wolf; the rolling 30-day baseline adapts to the store's own rhythm. 4. **Recovery is visible in the same card.** Once the courier credentials were refreshed and the queued labels flushed, the backlog drained overnight back to its normal \~39. The alert auto-cleared without manual intervention. ## Sibling cards merchants should reference together | Card | Why pair it with Order Processing Backlog | | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | [Pending Orders](/nerve-centre/kpi-cards/opencart/pending-orders) | The Pending component of the backlog, broken out so you can see whether the pile-up is at the payment stage or the packing stage. | | [Processing Orders](/nerve-centre/kpi-cards/opencart/processing-orders) | The Processing component. If Processing is the side that is growing, the bottleneck is fulfilment, not payment capture. | | [Order Status Distribution](/nerve-centre/kpi-cards/opencart/order-status-distribution) | The full status picture. When backlog spikes, this shows exactly which statuses absorbed the orders. | | [Platform Error Spike or Extension Conflict](/nerve-centre/kpi-cards/opencart/platform-error-spike-or-extension-conflict) | A stalled fulfilment flow is very often a broken shipping or payment extension. If both alerts fire together, you have your root cause. | | [Revenue at Risk (live)](/nerve-centre/kpi-cards/opencart/revenue-at-risk-live) | Puts a money figure on the stuck orders, useful for prioritising how hard to escalate. | | [Failed Orders (24h)](/nerve-centre/kpi-cards/opencart/failed-orders-24h) | If orders are failing rather than queueing, this is where they show up instead of in the backlog. | ## Reconciling against OpenCart **Where to look in the OpenCart admin:** Sales → Orders, then filter by Order Status. Set the filter to your pre-fulfilment statuses (Pending, Processing, or whatever your store calls them) and read the result count at the foot of the table. That count should track this card. Reports → Sales → Orders also breaks totals down by status if you want a status-by-status view over a date range. OpenCart admin views that *look* like the same number but aren't: * **The Dashboard "Total Orders" tile** counts all orders, not just the backlog. It will always be much larger. * **Sales → Orders with no status filter** shows every order ever placed; you must apply the status filter to isolate the backlog. * **Reports → Sales → Orders** is a value report by date range, not a live count of currently-stuck orders. **Why our number may legitimately differ from the OpenCart admin:** | Reason | Direction of divergence | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | **Timezone.** OpenCart stores order timestamps in the store timezone configured in System → Settings; Vortex IQ evaluates in UTC by default. Orders near a date boundary can shift the rolling-average baseline slightly. | Minor baseline drift | | **Multi-store.** A single install with several `store_id` storefronts aggregates here unless filtered. The admin order list can be filtered per store; the card defaults to all stores. | Vortex IQ higher if you are comparing against a single-store admin filter | | **Custom status mapping.** If your store added bespoke statuses (for example "Awaiting Stock"), whether they count as backlog depends on how they are mapped. Misconfigured mapping can include or exclude them. | Either direction | | **API / DB sync lag.** Vortex IQ reads from your OpenCart data on a sync cadence. An order created seconds ago may not yet be reflected. | Self-resolves at next sync | | **Order status filter scope.** The admin count depends on exactly which statuses you tick in the filter. The card uses your configured pre-fulfilment set. | Either direction if the filters disagree | **Cross-connector note:** if you also run a 3PL or courier integration, a backlog spike here should correlate with a drop in shipments confirmed on the carrier side. A backlog that climbs while the carrier reports normal pickups usually means the orders are stuck *before* the label step, inside OpenCart or a payment extension.
Same-metric documentation cross-reference (for agencies running multiple platforms) The same idea of an order-backlog alert exists on other commerce platforms. This is **not a reconciliation**, your OpenCart store has no parallel store on another platform to compare against. These links help agencies running multi-platform client books navigate between equivalent alerts. * [`shopify.fulfilment_delay_alert`](/nerve-centre/kpi-cards/shopify/fulfilment-delay-alert) * [`bigcommerce.fulfilment_delay_alert`](/nerve-centre/kpi-cards/bigcommerce/fulfilment-delay-alert)
## Known limitations / merchant FAQs **What exactly counts as "backlog"?** Orders in a pre-fulfilment status (typically Pending and Processing) that have not advanced to a completed or shipped state. Cancelled, Refunded, and Complete orders are excluded because they are resolved. **My store renamed "Processing" to "In Production", does the alert still work?** Yes. OpenCart stores statuses in `oc_order_status` and they are fully configurable. The alert keys on the statuses you have mapped as pre-fulfilment, not on the English word "Processing". **Why a 2x-average trigger instead of a fixed number?** Because every store's normal backlog is different, and the same store's normal varies by season. A fixed threshold of, say, 100 would never fire for a high-volume store and would fire constantly for a small one. The trailing 30-day average adapts to your own rhythm, so a genuinely busy but healthy day stays quiet while a true stall fires. **The alert fired during a flash sale, was that a false positive?** Not necessarily. A demand surge that outruns your packing capacity *is* a backlog, even if nothing is broken. The alert is telling you the queue is abnormal; your job is to decide whether to add packing hours or let it drain. A genuine fault and a genuine surge both deserve a look. **Does a backlog spike mean I am losing money?** Not directly, the orders are still placed and (usually) paid. But a long backlog risks late-delivery complaints, cancellations, and chargebacks. Pair this with [Revenue at Risk (live)](/nerve-centre/kpi-cards/opencart/revenue-at-risk-live) to see the value sitting in the queue. **My backlog never seems to clear, is the alert broken?** A chronically high backlog means your average fulfilment throughput is below your order rate. The alert is working; it is the operation that needs attention. Look at whether [Processing Orders](/nerve-centre/kpi-cards/opencart/processing-orders) grows faster than orders complete. **Does this count multi-store orders?** Yes, across all `store_id` values by default. If you want a single storefront's backlog, filter to that store. Be aware the admin order list can be filtered per store too, so compare like with like. **How fast does the alert clear after I fix the cause?** As soon as the backlog count drops back below the threshold at the next evaluation, the alert auto-clears. There is no manual dismissal required for a resolved backlog. *** ### Tracked live in Vortex IQ Nerve Centre *Order Processing Backlog* is one of hundreds of KPI pulses Vortex IQ tracks across OpenCart 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.