The live count of orders in a Processing status, paid and being picked or prepared but not yet shipped, complete, or otherwise closed.
At a glance
Processing is the healthy middle of the order lifecycle: payment has cleared and the warehouse or fulfilment team is working the order, but it has not yet shipped or been marked complete. A steady Processing count is the sign of a working operation. The number matters most as a flow reading: if Processing keeps climbing while shipped and complete counts stay flat, work is going in faster than it is coming out, and a fulfilment bottleneck is forming.
| What it counts | The number of orders whose current status is Processing. |
| Order source | Order records live in oc_order; the current status is held there and the full status history in oc_order_status / the order-history table. |
| What “Processing” means | Payment has been confirmed and the order is being prepared (picked, packed, awaiting dispatch). It is past Pending and not yet Shipped or Complete. |
| Relationship to other statuses | Pending sits before it; Shipped, Complete, Cancelled, and Refunded sit after it. The exact set of statuses is configurable per install. |
| Currency / value | This card counts orders, not money. OpenCart stores order totals and tax separately and supports multiple currencies. |
| Multi-store | Orders carry a store_id. By default this card counts Processing orders across every storefront on the install. |
| Time window | RT (live snapshot) |
| Alert trigger | None. This is a steady-state flow reading; pair it with the backlog card for alerting. |
| Roles | owner, operations |
Calculation
Worked example
A French apparel store on OpenCart 4.x shipping from a single warehouse. The team normally clears Processing within a day, holding a steady level of around 30 to 40 orders. The snapshots span a week in March.| Date | Processing count | Shipped that day | Read |
|---|---|---|---|
| 16 Mar 26 | 34 | 36 | Healthy, in roughly equals out |
| 17 Mar 26 | 38 | 35 | Healthy |
| 18 Mar 26 | 61 | 22 | Bottleneck forming |
| 19 Mar 26 | 88 | 19 | Backlog building fast |
| 20 Mar 26 | 41 | 70 | Caught up after adding pickers |
- The level alone is not the story; the flow is. A count of 34 on 16 Mar is fine because shipments roughly match it. The same count would be alarming if nothing was shipping. Processing is best read against the shipped count beside it.
- 18 to 19 Mar shows work backing up. Processing climbed from 38 to 88 while shipments fell to the teens. That gap, work in faster than out, is a fulfilment bottleneck (a sick picker, a courier no-show, a stockroom move), not a sales surge.
- This card has no alert by design. Processing is supposed to be non-zero, so a raw threshold would be noisy. The alerting job belongs to Order Processing Backlog, which watches the aging of unfinished work, not the instantaneous level.
- The recovery is visible too. On 20 Mar the team added pickers, shipments jumped to 70, and Processing fell back to 41. The card lets the owner confirm the fix worked, not just that a problem existed.
Sibling cards merchants should reference together
| Card | Why pair it with Processing Orders |
|---|---|
| Pending Orders | The stage before. Pending feeds Processing; if Pending is stuck, Processing starves. |
| Order Processing Backlog | The aging view that carries the alert. Processing is the level; the backlog watches how long orders sit. |
| Order Status Distribution | Shows Processing as a share of all statuses, useful for spotting an unhealthy mix. |
| Order Volume | Inflow context. A Processing climb during flat volume points to fulfilment, not demand. |
| Failed Orders (24h) | Orders that fail before reaching Processing never enter this count; a failure spike depresses it. |
| Revenue at Risk (live) | Puts a value on orders that have sat in Processing too long. |
Reconciling against OpenCart
Where to look in the OpenCart admin: Sales → Orders, then filter the Order Status column to “Processing”, gives you the same queue this card counts. Each order’s history tab (backed byoc_order_status and the order-history table) shows when it entered Processing and what came next. Reports → Sales → Orders can summarise counts by status across a period, which is the right place to see Processing against Shipped and Complete over time.
OpenCart admin views that look like the same number but aren’t:
- Sales → Orders with no status filter counts every order, not just Processing.
- The Dashboard “orders” tile is a recent-period count, not a live Processing level.
- A custom “Shipped” or “Awaiting Dispatch” status added by an extension can hold orders that you think of as “processing” but that this card does not count, because it keys off the Processing status specifically.
| Reason | Direction of divergence |
|---|---|
| Timezone. Vortex IQ reads on a UTC cadence; OpenCart timestamps follow the store timezone. A snapshot mid-shift can differ by a sync interval. | Cosmetic timing shift |
Multi-store. Orders carry a store_id; this card counts across all storefronts unless filtered. An admin filtered to one store shows fewer. | Card higher than a single-store admin view |
| Status-name customisation. OpenCart lets you rename or add statuses. A renamed Processing status or extra dispatch sub-statuses can shift what is counted. | Either direction |
| Workflow variations. Some merchants skip Processing and go Pending → Complete; their Processing count is naturally near zero. | Card lower for skip-Processing workflows |
| API / DB sync lag. An order that just advanced into Processing may not yet be reflected. | Self-resolves at next sync |
Known limitations / merchant FAQs
Why does this card have no alert? Processing is meant to be non-zero, so a raw threshold on the level would fire constantly. The useful alarm is about work aging, not work existing, which is why Order Processing Backlog carries the alert and this card stays a steady-state flow reading. My Processing count is always near zero, is something wrong? Not necessarily. Some merchants run a Pending → Complete workflow and never use Processing, or auto-advance orders past it. If your install does not route orders through a Processing status, a near-zero count is expected. Processing keeps climbing, what should I look at? Compare it with the shipped or complete count over the same days. If Processing rises while shipments stay flat, work is going in faster than it comes out, a fulfilment bottleneck. If both rise together, you are simply busier. I renamed Processing to “In Fulfilment”, will the card still count it? OpenCart lets you rename statuses. The card maps to the Processing status as configured for your install; a renamed status may need a one-time mapping adjustment so the right orders are counted. Does it count across all my storefronts? Yes by default. Orders carry astore_id, and the card sums Processing across every storefront unless you filter to one store.
An order is being packed but shows as Pending, not Processing, why?
Status reflects whatever the order record holds, not physical activity. If staff are working an order without advancing its status in OpenCart, it stays where it is. Keeping status changes in step with warehouse actions is what makes this card trustworthy.