> ## 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, Ecwid > Order Processing Backlog: detection-layer alert when orders awaiting processing exceed twice the 30-day average. 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 alarm when orders stuck awaiting processing pile up past twice your normal level. ## At a glance > A detection-layer alert that fires when the count of orders sitting in the AWAITING\_PROCESSING status rises above twice the trailing 30-day average. It is a fulfilment-bottleneck alarm, not a sales metric. A spike means orders are being paid for faster than they are being picked, packed, and moved to shipped, which for a small Ecwid seller usually means a holiday backlog, a sick day, a supplier delay, or a sudden viral order surge. | | | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The live count of orders whose fulfilment status is AWAITING\_PROCESSING (paid, not yet being fulfilled), compared continuously against the trailing 30-day average of that same count. | | **API endpoint** | `GET /v3/{store-id}/orders?fulfillmentStatus=AWAITING_PROCESSING` (paged, OAuth2 with `read_orders` scope). Webhook updates on `order.created`, `order.updated` keep the count live. | | **What counts** | Orders that are PAID and sitting in AWAITING\_PROCESSING. These are real, owed-to-the-customer orders awaiting action. | | **What it excludes** | Orders still awaiting payment (not yet the merchant's responsibility); orders already PROCESSING, SHIPPED, or DELIVERED; cancelled orders. | | **Currency** | Number. The card surfaces a count of orders and a multiple of the 30D average; it is not a money metric. | | **Time window** | `RT` (real-time count vs trailing 30-day average). | | **Alert trigger** | `>2x 30D avg AWAITING_PROCESSING`. | | **Sentiment** | Inverse gauge. Sensitive card; a backlog above the trigger is bad by definition, and the alert is the headline. | | **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 UK hobby seller of hand-poured candles running an Ecwid widget on a Wix site. The alert fires at 11:40 on 09 Dec 26, mid-festive-season.** The seller normally ships within a day, so the AWAITING\_PROCESSING queue rarely holds more than a handful of orders. A pre-Christmas push, plus two days away at a craft fair, let the queue build up unnoticed. **What tripped:** | Signal | Now | 30D average | Status | | ---------------------------- | ------ | ----------- | ---------------- | | Orders AWAITING\_PROCESSING | 23 | 9 | spiking | | Multiple of 30D average | 2.6x | 1.0x | above 2x trigger | | Oldest unprocessed order age | 3 days | \<1 day | ageing | ```text theme={null} Backlog multiple = 23 / 9 = 2.6x Trigger is >2x 30D average. Alert FIRES. Oldest order is 3 days old, well past the seller's same-day norm. ``` **What the merchant sees.** A red alert in the Nerve Centre alert feed reading "Order Processing Backlog, >2x 30D avg AWAITING\_PROCESSING", with the current count, the multiple, and the age of the oldest unprocessed order. The card distinguishes a genuine fulfilment pile-up from a normal busy day, because it benchmarks against this store's own 30-day baseline rather than a fixed number. **The playbook.** 1. Confirm it is real, not a sync artefact. If [Ecwid API Failure Rate Spike](/nerve-centre/kpi-cards/ecwid/ecwid-api-failure-rate-spike) is also firing, missed webhooks may have hidden then dumped a batch; treat the API alert first. 2. Triage by age. Process the oldest orders first to protect delivery promises; the card surfaces the oldest-order age so you know how exposed you are. 3. Decide on capacity. For a one-person hobby store, a 2.6x backlog at peak may simply mean a long packing session is needed; for a busier store it may mean adding a helper for the week. 4. Communicate. If the backlog cannot clear within the normal dispatch promise, a short "shipping in 2 to 3 days due to high demand" banner on the storefront protects against refund requests and bad reviews. 5. Watch it drain. The count should fall back under 2x the average as orders move to PROCESSING and SHIPPED. The card exists because a small seller cannot eyeball a queue while away from the desk. It turns "I think I'm behind" into "you are 2.6x your normal, oldest order is 3 days old". ## Sibling cards merchants should reference together | Card | Why it matters next to this alert | What the combination tells you | | ------------------------------------------------------------------------------------------ | --------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | [Orders by Status](/nerve-centre/kpi-cards/ecwid/orders-by-status) | The full status picture. | Shows whether the backlog is awaiting-processing only, or if shipped / delivered counts are also stalled. | | [Pending Orders](/nerve-centre/kpi-cards/ecwid/pending-orders) | Adjacent queue. | A pending-payment build-up upstream feeds the processing queue once those orders clear. | | [Avg Order Fulfillment Time](/nerve-centre/kpi-cards/ecwid/avg-order-fulfillment-time) | The speed metric. | A rising fulfilment time alongside the backlog confirms a genuine capacity problem, not a blip. | | [Order Volume](/nerve-centre/kpi-cards/ecwid/order-volume) | The inflow. | A demand spike explains a backlog as success, not failure; flat volume with a backlog means a processing slowdown. | | [Ecwid API Failure Rate Spike](/nerve-centre/kpi-cards/ecwid/ecwid-api-failure-rate-spike) | Sync sanity check. | Missed webhooks can hide then dump a batch; rule this out before assuming a real pile-up. | | [Awaiting Payment Orders](/nerve-centre/kpi-cards/ecwid/awaiting-payment-orders) | Upstream pressure. | A large awaiting-payment cohort about to clear signals the processing queue is about to grow. | | [Cancellation Rate](/nerve-centre/kpi-cards/ecwid/cancellation-rate) | The cost of delay. | A backlog left too long shows up later as cancellations from impatient buyers. | ## Reconciling against Ecwid **Where to look in Ecwid's own dashboard:** > **Ecwid Control Panel (`my.ecwid.com`) -> My Sales -> Orders -> filter by fulfilment status "Awaiting Processing"** > Count the filtered list; it is the apples-to-apples comparison against this card's current count. For the baseline, the card's 2x multiple is computed by Vortex IQ from 30 days of history and is not shown directly in the Ecwid Control Panel. **Why our number may differ from Ecwid's Control Panel:** | Reason | Direction | Why | | ------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Status mapping** | Either | Ecwid lets merchants rename or add custom fulfilment statuses; we map anything semantically equal to "awaiting processing" into the count, which may differ from a literal status filter. | | **Sync lag** | Ours occasionally lower | Webhook-driven; the most recent few minutes of new orders may not yet be in the count. | | **Time zone** | Boundary effect | Order-age calculations use UTC; Ecwid shows store-local timestamps, so the oldest-order age may read slightly differently at day boundaries. | | **Baseline window** | Ours only | The 2x trigger uses our trailing-30-day average; the Ecwid Control Panel shows only the live list, not the benchmark. | **Internal identity:** `ecwid_order_processing_backlog = count(AWAITING_PROCESSING)`, with the alert firing when that count exceeds 2x its trailing 30-day average. ## Known limitations / merchant FAQs **Does this mean I have lost orders?** No. Every order in this count is paid and present; it just has not moved to processing yet. The alert is telling you the queue is bigger than normal, so customers are waiting longer than usual. **Why benchmark against my own 30-day average instead of a fixed number?** Because a backlog of 20 is a crisis for a store that normally has 3 awaiting orders and a quiet Tuesday for a store that normally has 50. The 2x multiple adapts to each store, so the alert means "abnormal for you" rather than an arbitrary count. **It fired during my busy season. Is that a false alarm?** Not exactly. A demand surge is a good problem, but the alert is still correct: customers are waiting longer than your baseline. Use it as a prompt to add capacity or set delivery-time expectations on the storefront, not as a sign something is broken. **The count looks too high compared with my Ecwid Control Panel. Why?** Usually custom status naming. If you renamed or added fulfilment statuses in Ecwid, our mapping of "awaiting processing" may catch orders a literal filter misses. Reconcile by checking what each custom status means. **The count jumped suddenly with no new sales. What happened?** Likely a recovered sync. If [Ecwid API Failure Rate Spike](/nerve-centre/kpi-cards/ecwid/ecwid-api-failure-rate-spike) fired earlier, missed `order.created` webhooks can dump a batch into the queue all at once when sync resumes. Treat the API alert as the root cause. **How do I clear the alert?** Process the awaiting orders. As they move to PROCESSING and SHIPPED the count falls; once it drops under 2x your 30-day average the alert resolves automatically. **Can I change the 2x threshold?** Yes, the multiple is configurable per merchant. A store with very spiky demand may prefer 3x to cut noise; a store with a strict same-day promise may want 1.5x to catch slippage early. **Does the oldest-order age affect whether it fires?** The trigger is the count multiple, not age. But the card surfaces the oldest-order age alongside the count so you can judge severity; 23 orders that are all from this morning is less urgent than 23 where the oldest is three days old. **My store is seasonal and quiet right now. Could a tiny absolute count fire this?** Possibly. If your 30-day average is very low (say 2), even 5 awaiting orders is 2.5x and will fire. For very low-volume stores, consider raising the multiple or watching the absolute count instead, since small numbers swing wildly. *** ### Tracked live in Vortex IQ Nerve Centre *Order Processing Backlog* is one of hundreds of KPI pulses Vortex IQ tracks across Ecwid 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.