At a glance
Real-time SLA tracker that measures hours elapsed between an Adobe Commerce order entering state = processing (paid) and the first shipment being created against it. Fires when more than 50 orders have been sitting unshipped for over 48 hours. Designed to catch warehouse-floor problems (a packer out sick), 3PL outages (the integrator’s API queue is backed up), or carrier collection failures (the courier missed pickup) before customer complaints arrive.
| What it counts | For each open order: now() - max(updated_at WHERE state transitioned to processing). The card excludes orders already shipped. The “first shipment” trigger uses Adobe Commerce’s shipment entity (a separate document, created via POST /rest/V1/order/{id}/ship); the existence of any shipment for an order moves it from “open SLA clock” to “shipped, no longer counted”. |
| API field | state, created_at, updated_at from GET /rest/V1/orders; shipment existence via GET /rest/V1/orders/{id}/shipments or by querying the shipment index directly. |
| VAT / tax treatment | n/a, this is a time-elapsed alert, not a value alert. |
| Shipping inclusion | n/a for the alert. The companion roll-up (orders by SKU category) uses shipping_amount to estimate logistics cost at risk. |
| Discounts | n/a. |
| Credit Memo refund treatment | Refunds before shipment effectively cancel the SLA clock (refunded orders move to a different state), so they self-resolve. Credit Memos issued post-shipment do not affect this card. |
state machine inclusion | Numerator is orders in state = processing only. Excluded: pending_payment (not yet paid, no SLA owed), holded (deliberately frozen by ops), complete (already invoiced and typically shipped), closed, canceled. |
pending_payment quirk | Excluded by design. SLA only starts when the customer has paid. A flood of pending_payment orders does not count toward fulfillment delay; check Order State Distribution for that signature. |
holded quirk | Adobe Commerce uniquely supports a holded state where ops manually pauses an order (typical use: fraud review, B2B credit check, custom-make order awaiting design approval). Holded orders do not count, the SLA clock pauses while held and resumes on un-hold. This is correct: a 5-day fraud review should not flag fulfillment delay. |
Multi-currency grand_total vs base_grand_total | n/a for the alert (count-based). The companion “value at risk” estimate uses base_grand_total to roll up across currencies. |
Store View scope (store_id) | All Store Views by default. For multi-warehouse Adobe Commerce installations using MSI source-stocks, configure per-source variants if your warehouses operate independently. |
| Time window | RT (real-time). |
| Alert trigger | >50 orders unshipped >48h. The 48-hour window matches typical merchant promise; the 50-order threshold filters routine variance from genuine backlog. |
| Sentiment key | fulfillment_rate |
| Roles | owner, operations |
Calculation
Calculated automatically from your Adobe Commerce 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 nutritional supplements brand on Adobe Commerce 2.4.6 with a US Store View, a UK Store View, and a B2B portal. Two 3PL warehouses (US: ShipBob Carlsbad, UK: Huboo Bristol). The merchant promises 24-hour dispatch on consumer orders and 72-hour dispatch on B2B orders. Snapshot taken Friday 22 Apr 26, 16:00 GMT. The alert just fired. Open orders by warehouse and age:| Warehouse | <24h | 24-48h | >48h | Total open |
|---|---|---|---|---|
| US (ShipBob Carlsbad) | 142 | 38 | 14 | 194 |
| UK (Huboo Bristol) | 86 | 110 | 74 | 270 |
| B2B (manual fulfilment from HQ) | 12 | 8 | 3 | 23 |
| Total | 240 | 156 | 91 | 487 |
| Warehouse | Median age of >48h cohort | 7-day baseline | Variance |
|---|---|---|---|
| US | 53h | 47h | within range |
| UK | 71h | 38h | +87%, anomalous |
| B2B | 60h | 60h | as expected (B2B 72h SLA) |
- The UK warehouse is the problem. 74 of the 91 over-SLA orders are at Huboo Bristol. Median age in the over-SLA cohort is 71 hours, almost a full day past the SLA breach.
- The US warehouse is operating within normal variance. 14 orders over 48h is light backlog, not a regression.
- The B2B portal at 60 hours is expected because that 3-order cohort is in the merchant’s promised 72h B2B SLA. They are not yet in breach.
- Investigation reveals: Huboo Bristol’s pick-pack staffing dropped Wednesday afternoon (a packer called in sick, the planner did not flex) and the backlog has compounded over Thursday and into Friday morning. Carrier pickup at 14:00 today only cleared the 24-hour-old cohort.
- Action: weekend overtime for two pickers will clear the backlog by Sunday evening. Customer service should send proactive “shipping delayed by 1 to 2 days” emails to the 74 affected customers (Adobe Commerce admin > Sales > Orders > select with filter > Email Update). This converts a complaint into a positive (proactive comms is itself a retention signal).
- Revenue at risk: 74 affected orders × ~4,290 of potential cancellations and refunds if the delay extends past 96 hours. Adobe Commerce will not auto-cancel, but customers do request refunds at the 4-day mark in measurable numbers.
Sibling cards merchants should reference together
A fulfillment alert is most useful when triangulated against operational and customer-facing cards.| Card | Why pair it with Fulfilment Delay Alert |
|---|---|
| Unfulfilled Orders | The denominator and detail grid. The alert is a derivative of this card’s open-order list filtered to >48h. |
| Fulfilment Rate | The trailing percentage view. A 7-day fulfillment rate dropping from 96% to 88% confirms the backlog is sustained, not a single bad day. |
| Fulfilment Over Time | The chart view. Look for the inflection point where backlog started accumulating. |
| Fulfilment Breakdown | Splits open orders by status/source/warehouse. Identifies which warehouse is the bottleneck. |
| Order State Distribution | If holded orders are unusually high, ops has paused fulfillment deliberately (fraud review, credit-check queue) and the alert may be expected, not anomalous. |
| Cancellation Rate | The lagging consequence. Customers who wait past 96h cancel at a measurable rate; cancellation rate rising 2-4 days after a fulfillment alert is the cost. |
| Refund Rate | Same lagging effect. Some customers receive late, accept the delivery, and then refund anyway. |
shopify.shopify_alert_fulfilment_delay | Cross-platform peer for agency teams. |
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin: Adobe Commerce ships with reasonable native fulfillment views:Sales > Orders with the Status filter set to “Processing” gives the open-order list. Sort by Purchase Date ascending and the oldest unshipped orders rise to the top. Adobe does not natively compute “hours unshipped”; you have to mentally subtract the Purchase Date from now.For the shipment side:
Sales > Shipments lists every shipment created in the period. The lack of a shipment for a processing order is what this alert is detecting.
For multi-source (MSI) merchants:
Stores > Inventory > Sources shows configured stock sources. Combined with Sales > Orders > [Order] > Source assignment, you can identify which warehouse owns each unfulfilled order.Other Adobe Commerce Admin views that look relevant but are not:
- Reports > Sales > Shipping: shipping cost aggregations, no per-order SLA detection.
- Reports > Sales > Invoiced: invoiced amount, separate from shipment.
- Reports > Sales > Orders: aggregated by date, no SLA dimension.
- Stores > Configuration > Sales > Shipping Methods: configuration, not live state.
| Reason | Direction of divergence |
|---|---|
Time-zone. Adobe stores created_at and updated_at in server timezone (often UTC, but configurable). The card uses UTC. Hour-level boundaries can shift the >48h cohort by ±1. | ±1 order on the boundary |
holded exclusion. The card excludes orders in holded state. The Admin “Processing” filter does the same, but if you check the “All” status filter you’ll see them. | Vortex IQ count lower than admin All-status count |
Partial shipment. Adobe allows partial shipments (some line items shipped, others not). The card treats any shipment as “fulfillment started”; an order with 1 of 5 items shipped no longer counts. The Admin order-status remains processing until all items ship. | Vortex IQ count lower for partial-ship operations |
| B2B 72h SLA. The card’s 48h threshold is consumer-oriented. B2B orders within 48-72h are not yet breached but appear in the >48h cohort. Configure per-Store-View thresholds. | Vortex IQ may flag B2B orders as breached when the merchant’s own SLA allows them |
| Sync lag. The card uses the most recent OpenSearch sync (5-15 min). Admin is live. | Vortex IQ slightly stale at the boundary |
| Pair | Expected relationship | What divergence tells you |
|---|---|---|
| 3PL connector (ShipBob, Huboo, ShipStation) order-queue depth | Should rise when this card is rising | If the 3PL queue is empty but Adobe shows backlog, the issue is the integration (orders not pushing to 3PL). If the 3PL queue is deep, it is genuine warehouse backlog. |
| Carrier API tracking-event volume | Should drop when this card is rising | Carrier scan rate falling for outbound parcels confirms the warehouse is producing fewer ready parcels. |
stripe.stripe_chargebacks | Lagging effect, expect chargeback risk to rise 14-30 days after sustained fulfillment delays | Customers who never received goods file chargebacks when refund requests are denied. |
Known limitations / merchant FAQs
The alert fired but my warehouse says nothing’s wrong, why? Two common reasons. First, the issue may be in the integration layer rather than the warehouse itself: orders are sitting in Adobe Commerce inprocessing but never reaching the 3PL because the API push is failing silently. Check your integration logs (or the 3PL queue depth via the connector). Second, partial shipments: Adobe Commerce allows shipping some items but not others; an order with 1 of 5 SKUs shipped is removed from this card’s count, but the warehouse view may show the remaining 4 items as outstanding work.
What’s the difference between state and status and how does it affect this alert?
state is the system lifecycle (8 fixed values); status is configurable. This alert filters on state = processing because that’s the universal “paid, not shipped” lifecycle position. Custom statuses you’ve layered on top (e.g. “Awaiting Pick”, “Pick Complete”, “Pack Complete”) all sit within state = processing and are correctly counted by this alert.
Adobe Commerce vs Magento Open Source: any difference for this card?
The shipment entity exists in both editions and the state lifecycle is identical. Adobe Commerce edition adds the Order Management System (OMS) integration which can change where shipment-creation happens; if your installation uses OMS, ensure the OMS-to-Adobe webhook is firing or the card will undercount shipped orders.
Why does the card use 48 hours rather than my SLA of 24 hours?
The default threshold is consumer-norm. Configure your own threshold in the manifest if your promise is shorter (24h same-day) or longer (72h B2B). The 50-order count threshold is also tunable; very high-volume stores want it higher to filter routine variance.
My multi-warehouse Adobe Commerce, can I see per-warehouse alerts?
Yes, configure per-MSI-source variants. The default card aggregates; multi-warehouse merchants benefit greatly from per-source variants because the root cause is almost always at one specific warehouse, not the whole network.
The B2B portal has different SLAs, will the alert handle that?
Not by default. Set up a per-Store-View variant for the B2B Store View with a longer threshold (typical B2B SLA is 72 hours, sometimes 5 working days for custom-build B2B orders). Without the variant, the consumer-norm 48h threshold will spuriously flag B2B orders that are still within their own SLA.
Why doesn’t holded count toward fulfillment delay?
Adobe Commerce’s holded state is an explicit “operations has paused this order” signal. Common uses: fraud review, B2B credit-check queue, custom-make awaiting design approval. The SLA clock should pause while held; resuming when the order is un-held. Counting holded orders would conflate “warehouse is slow” with “ops deliberately froze it”, masking the genuine problem signal.
pending_payment orders are sitting forever, why aren’t they flagged?
This card excludes pending_payment because the merchant has no fulfillment obligation until the customer has paid. A flood of pending_payment is a different problem (gateway callback failure or net-30 PO routing issue); use Order State Distribution to monitor it.
My 3PL completes shipment but the Adobe order stays processing, why?
The 3PL needs to call back to Adobe (typically via webhook) to register the shipment. If the webhook is failing, the 3PL has shipped but Adobe doesn’t know. The card will overcount unshipped orders in this scenario. Symptoms: a stable >48h cohort that doesn’t grow but also doesn’t drain. Check your 3PL integration’s webhook status and replay any failed deliveries.