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 |
- 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.
- 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.
- 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.
- 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 | 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 | The Processing component. If Processing is the side that is growing, the bottleneck is fulfilment, not payment capture. |
| Order Status Distribution | The full status picture. When backlog spikes, this shows exactly which statuses absorbed the orders. |
| 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) | Puts a money figure on the stuck orders, useful for prioritising how hard to escalate. |
| 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.
| 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 |
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 inoc_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) 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 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.