Anomalous OOS spike, usually a misconfigured sync, hold, or sudden demand event. Pair with the cross-platform ad-spend card.
At a glance
Real-time anomaly alert: the OOS variant count has jumped more than 2 standard deviations above its 30-day baseline. Catches misconfigured-sync events, accidental holds, and sudden viral-demand spikes before customer-service queues fill.
Calculation
Calculated automatically from your Shopify 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 US apparel DTC brand on Shopify Plus, ~3,200 active variants, 30D baseline OOS count = 22 (σ = 6). Tuesday 06 May 26, 09:00 PT, the alert fires: OOS count = 87. That’s 65 above mean, ~10σ above baseline. Drill-down by product family reveals:
Six things to notice:
- The expected spike (drop launch) was within tolerance. Linen + trouser + bucket hat drop on 04 May, OOS rising over 48 hours is the signature; the brand should have absorbed it via reorder POs already placed.
- The unexpected spike is in core basics. 18 core-basic variants OOS is 6× normal. This isn’t a launch event; something broke. Check 1: did inventory sync from the warehouse stop? Check 2: did the cycle count get re-imported with stale data?
- The cause was a 3PL sync glitch. Investigation reveals the warehouse barcode-scanner system pushed stale “0” counts for 18 SKUs to Shopify at 03:00 PT. The actual physical inventory is fine; this is a data fault.
- Customer impact is live. Every minute these 18 SKUs show as OOS, the storefront blocks orders. Estimate: 18 SKUs × ~4 orders/SKU/hour normal velocity = 72 orders blocked. Cross-reference Active Ads on OOS, every Google Ads click on these 18 SKUs is wasted CPC right now.
- The fix is fast. Manually re-publish inventory levels from the WMS to Shopify; SKUs typically come back in stock within 5-10 minutes. Then run a full reconciliation.
- Document the lesson. A 03:00 cron job hit a corrupt CSV; review the WMS-to-Shopify sync pipeline for resilience. Add a sanity check (refuse imports where >10 SKUs go to zero in one batch).
Sibling cards merchants should reference together
The OOS-spike alert is the trigger. The investigative companions:Reconciling against the vendor’s own dashboard
Where to look in Shopify Admin: Shopify doesn’t expose a dedicated OOS-spike alert. The closest reconstructions:- Products → Inventory with filter Available: 0 or less and Status: Active: gives the current OOS count. Comparing that to your typical baseline (you’ll have to remember it) gives the “is this a spike?” answer.
- Home → Notifications: low-stock notifications, but at a per-SKU level, not aggregate.
- Apps like Stocky / Inventory Planner: typically expose stockout-risk and forecasting; alert profiles vary.
Cross-connector reconciliation:
Known limitations / merchant FAQs
Why does the alert fire when I just launched a new collection? Launches naturally spike OOS as customers buy through inventory. The 2σ threshold is generic; for known launch days, either:- Pre-emptively raise the threshold for that 48-72h window via the Nerve Centre → Alerts → Suppress feature.
- Accept the false-positive and treat it as a “drop is going well” signal rather than an incident.
- The OOS rise is gradual over many days (the daily delta is below 2σ even though cumulative OOS is high). Use the underlying count card alongside.
- The OOS rise is on a per-SKU basis but the count aggregate is unchanged because other SKUs restocked simultaneously.
- Open the OOS list sorted by velocity (units sold last 30 days desc).
- Identify the cause cluster: is it concentrated on one product family, one location, one batch? Pattern usually reveals cause.
- Distinguish data-fault vs real OOS: if 10+ SKUs went to zero simultaneously, it’s almost always a sync fault, not real demand. Verify via WMS / 3PL.
- For real demand: place emergency reorder on top-velocity OOS SKUs; pause ads on OOS variants.
- For data fault: re-sync inventory from source; investigate the cron / pipeline that introduced the fault.
- Document and prevent in your ops runbook.