Orders not yet processed or fulfilled; the backlog indicator.
At a glance
Live count of paid orders that have not yet been processed or fulfilled. This is the single most actionable operational number for a small Ecwid merchant: it is the pile of boxes still to pack. Each pending order is a paying customer waiting. The card is a real-time backlog gauge, and its alert fires when the queue swells well beyond the store’s normal daily rhythm, the signal that sales have outrun packing capacity or that something has stalled the line.
| What it counts | COUNT(orders WHERE paymentStatus = PAID AND fulfillmentStatus NOT IN (SHIPPED, FULFILLED, DELIVERED)), evaluated in real time. These are paid orders awaiting action. |
| API endpoint | GET /v3/{store-id}/orders (paged, max 100 per call, OAuth2 with read_orders scope). The engine reads each order’s paymentStatus and fulfillmentStatus. Webhook updates fire on order.paid and order.updated. |
| What “pending” includes | Paid orders that are new, awaiting processing, or partially prepared but not yet shipped or marked fulfilled. |
| What it excludes | Orders still AWAITING_PAYMENT (those are in Awaiting Payment Orders), cancelled orders, and orders already shipped, fulfilled, or delivered. |
| Backlog vs throughput | This card is the live level (the queue right now). Pair it with Avg Order Fulfillment Time for the rate at which the queue drains. |
| VAT / tax / shipping | Not relevant; this is an order-count card, not a value card. |
| Currency | number. A count of orders, not a money figure. |
| Time window | RT (real time). The card shows the current live backlog, not a rolling window. |
| Alert trigger | >2x 30D avg. When the live pending count exceeds twice the store’s trailing 30-day average backlog, the queue has broken its normal rhythm. |
| Sentiment | ecwid_pending_orders. Inverse: lower is better. |
| Roles | owner, operations. |
Calculation
Calculated automatically from your Ecwid 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 small UK soap and bath-bomb maker running an Ecwid widget on their Instant Site, snapshot taken 21 Apr 26 after a weekend market post went viral. The maker normally carries a handful of pending orders, clearing them in one evening packing session. A short video of a bath bomb fizzing got picked up over the weekend and orders surged.| Snapshot | Today (21 Apr 26) | 30D avg backlog | Multiple |
|---|---|---|---|
| Pending Orders (this card) | 64 | 9 | 7.1x |
| Orders paid in last 48h | 71 | n/a | n/a |
| Avg Order Fulfillment Time | 58h | 28h | +30h |
Sibling cards merchants should reference together
| Card | Why it matters next to pending orders | What the combination tells you |
|---|---|---|
| Avg Order Fulfillment Time | The drain rate. | High backlog + rising fulfilment time = the queue is winning; add capacity now. |
| Order Processing Backlog | Aged-order detail. | Tells you whether the pending pile is fresh demand or old stuck orders. |
| Awaiting Payment Orders | The upstream stage. | Pending counts paid orders only; awaiting-payment is the queue feeding in behind it. |
| Total Orders | Volume context. | A backlog spike with an order spike is demand; a backlog spike without one is a stall. |
| Low Stock Products | Hidden blocker. | A surge can empty the hero SKU mid-backlog, turning pending orders into cancellations. |
| Cancellation Rate | The failure mode. | A backlog left too long ages into cancellations; watch both during a surge. |
| Total Revenue | The value at stake. | The backlog is paid revenue you must now deliver; size it against the day’s takings. |
| Order Volume | Inflow rate. | Compares how fast orders arrive against how fast you clear the pending queue. |
Reconciling against Ecwid
Where to look in Ecwid’s own dashboard:
Ecwid Control Panel (my.ecwid.com) -> My Sales -> Orders -> filter Fulfillment status = “Awaiting Processing” / “Processing” (and Payment status = “Paid”)
The count of paid, not-yet-shipped orders is the apples-to-apples comparison.
For a quick view, the Ecwid Orders screen highlights new and unshipped orders at the top of the list; the unshipped run is your backlog.
Why our number may differ:
| Reason | Direction | Why |
|---|---|---|
| Status mapping | Either | Ecwid stores can configure custom fulfilment statuses; we treat anything not shipped/fulfilled/delivered as pending, which may group statuses your dashboard shows separately. |
| Paid-only scope | Ours lower | We count only paid orders as pending; a dashboard view that includes unpaid orders in its “to do” list will read higher. |
| Time zone | Marginal | Real-time count, but the 30D average used for the alert is computed in UTC; Ecwid uses store-local. |
| POS / instant fulfilment | Ours lower | POS and digital orders fulfil instantly and never enter the pending pile. |
| Sync lag | Marginal | Webhook-driven; an order just marked shipped may take a polling cycle to leave the count. |
ecwid_pending_orders = COUNT(orders WHERE PAID AND NOT shipped/fulfilled/delivered), with the alert when this exceeds 2 x trailing_30D_average.
Known limitations / merchant FAQs
What exactly counts as a pending order? A paid order that has not yet shipped, been fulfilled, or been delivered. It is the pile still to pack. Unpaid orders are not here, they are in Awaiting Payment Orders. Why is the alert based on a multiple of my average rather than a fixed number? Because a healthy backlog for a five-orders-a-week store is wildly different from a fifty-orders-a-day store. Keying the alert to 2x your own 30-day average makes it meaningful for any size of Ecwid store without manual tuning. My pending count spiked but it is just a busy day. Is that bad? Not inherently. A backlog spike alongside an order spike is demand, which is good news with an operational task attached. The risk is letting the pile age. Watch Avg Order Fulfillment Time to see whether you are keeping pace. The count is high but orders are not arriving. What does that mean? A backlog rising without new orders is a stall: something stopped you clearing the queue (you were away, a supplier delayed you, a hero SKU sold out). Check the backlog and low-stock cards to find the blocker. Do digital products and POS sales show up here? Rarely. Digital products auto-fulfil at payment and POS orders fulfil in person, so both skip the pending state. This card is mostly about physical orders you ship. How do I clear a backlog fastest without making mistakes? Triage oldest-paid first, batch by product to reduce pick errors, and set a visible dispatch-time expectation on your storefront so customers know what to expect. Rushing raises packing errors, which then show up later as refunds, so steady beats frantic. Will a stuck order inflate this forever? It stays pending until you ship, fulfil, or cancel it. If one order is permanently stuck (a backorder, a custom item awaiting a supplier), it will sit in the count. Use the backlog card to spot aged outliers and decide whether to split them onto a made-to-order workflow. How fresh is the count? It is real time, refreshed each polling cycle and on theorder.paid and order.updated webhooks. An order leaves the count within moments of being marked shipped or fulfilled.