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 |
- Confirm it is real, not a sync artefact. If Ecwid API Failure Rate Spike is also firing, missed webhooks may have hidden then dumped a batch; treat the API alert first.
- 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.
- 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.
- 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.
- Watch it drain. The count should fall back under 2x the average as orders move to PROCESSING and SHIPPED.
Sibling cards merchants should reference together
| Card | Why it matters next to this alert | What the combination tells you |
|---|---|---|
| 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 | Adjacent queue. | A pending-payment build-up upstream feeds the processing queue once those orders clear. |
| Avg Order Fulfillment Time | The speed metric. | A rising fulfilment time alongside the backlog confirms a genuine capacity problem, not a blip. |
| 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 | Sync sanity check. | Missed webhooks can hide then dump a batch; rule this out before assuming a real pile-up. |
| Awaiting Payment Orders | Upstream pressure. | A large awaiting-payment cohort about to clear signals the processing queue is about to grow. |
| 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. |
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 fired earlier, missedorder.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.