Unusual stock-out velocity, a viral SKU, a fulfilment-system glitch, or a feed re-import. Investigate before ads waste spend.
At a glance
Real-time alarm when more than five SKUs flip from in-stock to out-of-stock within a single hour. Catches a viral SKU running out faster than the merchant noticed, a fulfilment-system glitch zeroing inventory by mistake, or a feed re-import that wiped stock levels. Where Shopify’s app marketplace surfaces dozens of inventory-monitoring add-ons, BigCommerce merchants typically rely on the platform’s native inventory tracking and a tighter set of integrations, making this real-time signal more important.
| What it counts | COUNT(DISTINCT product_id WHERE inventoryLevel transitioned from >0 to 0 in last 60 min). Each SKU contributes once even if its inventory bounced. The alert evaluates every 5 minutes and fires when the count exceeds 5 for any rolling 60-minute window. |
| API endpoint | BC Catalog v3 webhooks/store/product/inventory/order_updated and store/product/inventory/updated events plus reconciliation against the products index. Inventory transitions are timestamped at the BC-side webhook receipt time. |
| VAT / tax treatment | n/a, inventory event metric. |
| Shipping | n/a. |
| Discounts | n/a. |
| Refunds | n/a, but a refund that returns stock to inventory does NOT undo a prior OOS event for alert purposes. |
| Cancelled orders | n/a, the alert counts SKU state transitions, not orders. |
| Currency | n/a. |
| Channels | All channels. The alert fires once store-wide rather than per-channel; per-channel OOS detail surfaces in BC Channel OOS per Channel. |
| B2B Edition behaviour | B2B portal SKUs share the same inventory pool by default; an OOS event affects both DTC and B2B simultaneously unless the merchant configures customer-group-specific inventory pools (rare, but supported on Enterprise). |
| Multi-Location Inventory | When MLI is enabled the alert evaluates per-location; an SKU OOS at warehouse A but in-stock at warehouse B counts as OOS only if all locations zero. Configure per-location alerts if location-specific operations matter (fail-over fulfilment between warehouses). |
| Catalogue feed re-imports | The single most common cause of this alert firing falsely is a catalogue feed re-import that briefly zeroes inventory before re-populating. The alert applies a 5-minute settling window to filter these; if the count returns to in-stock within 5 minutes, the event is suppressed. |
| Time window | RT (rolling 60-minute window evaluated every 5 minutes). |
| Alert trigger | >5 SKUs flipped to OOS in 1h |
| Sentiment key | out_of_stock_count |
| Roles | owner, operations, marketing |
Calculation
Calculated automatically from your BigCommerce 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 homewares brand on BigCommerce Pro. Snapshot at 11:00 UTC on Friday 17 Apr 26.| Time | SKU | Channel availability | Pre-OOS daily revenue |
|---|---|---|---|
| 10:08 | ”Linen sheet, King, Ivory” | All channels | $340/day |
| 10:14 | ”Linen sheet, King, Sage” | All channels | $280/day |
| 10:19 | ”Linen sheet, King, Charcoal” | All channels | $220/day |
| 10:31 | ”Linen sheet, Queen, Ivory” | All channels | $410/day |
| 10:44 | ”Linen sheet, Queen, Sage” | All channels | $290/day |
| 10:52 | ”Linen sheet, Queen, Charcoal” | All channels | $250/day |
| Count in 60min window | 6 SKUs | ~$1,790/day exposure |
- The pattern reveals the cause. Six bedding SKUs in the same product family, all king and queen sizes, all colours, all dropping within 45 minutes. This is not natural buyer demand; this is a catalogue sync event (warehouse just reported the linen-set lot finished) or a viral moment (a TikTok influencer posted, demand surged across the family). Same alert, two completely different responses.
- Diagnostic sequence in the first 5 minutes: (a) Check Channel Manager Activity log for any feed re-imports in the last hour, false-positive culprit #1. (b) Check BC Top SKUs Revenue for any of these SKUs spiking, that’s a viral signal. (c) Check warehouse / 3PL inventory feed for the lot status. (d) Check social platforms for the SKU getting tagged.
- If viral, the action is “raise prices and pause ads”. Six SKUs at 50k/month at full velocity; if a viral wave is doubling that, the right move is to capture the demand at higher price (10-20% lift on the in-stock siblings) and pause ads pointing at the OOS SKUs to avoid wasted spend.
- If catalogue glitch, the action is “freeze the feed and roll back”. A re-import that wiped inventory should be obvious in Channel Manager logs; pause the source feed, manually restore the inventory from the warehouse export, and investigate the feed-pipeline regression before resuming.
- The Amazon penalty exposure is significant. Six SKUs going OOS on Amazon simultaneously can trigger a buy-box loss across the whole product family. Set Channel Manager → Amazon to auto-hide on OOS rather than leaving zombie listings; an Amazon delisting recovers within hours, but a buy-box loss can take weeks.
- Determine cause (viral vs glitch vs ordinary). Viral has supporting BC Top SKUs signal; glitch has Channel Manager log signal.
- Pause ads pointing at affected SKUs immediately. Every minute of paid traffic to OOS pages is wasted spend.
- Auto-hide on marketplaces to protect ranking and avoid buy-box loss.
- Communicate restock timing if known. Customers convert at 12-25% on back-in-stock email if you have their address; capture them.
- Document the cause for post-incident review. Repeat OOS events on the same SKU family flag a deeper inventory-planning issue.
Sibling cards merchants should reference together
| Card | Why pair it with OOS Spike Alert |
|---|---|
| BC Channel OOS per Channel | The static count view; this card is the rate-of-change view. |
| BC Stock vs Sales | The velocity-weighted view. Tells you which OOS items are urgent (high velocity) vs tail (can wait). |
| BC Top SKUs | Cross-reference: if your top sellers appear in this alert, it’s a five-alarm event. |
| BC Top SKUs Revenue | The revenue-impact view; multiply OOS velocity by hours-OOS. |
| BC Inventory Distribution | The healthy-stock baseline. Lets you see whether OOS is concentrated or distributed. |
| BC Channel Inventory Split | If MLI is enabled, surfaces per-location stock. |
| BC Alert Channel Revenue Drop | Often co-fires when the OOS event hits a high-revenue channel. |
| BC XC Ads on OOS | Cross-connector; surfaces ad spend pointed at OOS items. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Products → View, filter byInventory Level = 0, sort by Last Modified descending; the most recent flips to zero appear at the top. Compare against this card’s count for the last hour.
For the operational source: Channel Manager Activity log shows feed events; if a sync just ran, that’s almost certainly the cause.
For Multi-Location Inventory: Settings → Inventory → Locations shows per-location stock.
Why our number may legitimately differ from BC’s recent-changes view:
| Reason | Direction |
|---|---|
| Webhook delivery lag. Inventory webhooks can lag the actual change by 30-120 seconds during peak load. | Vortex IQ slightly LAGS BC for short windows |
| Variant vs product. We count variant transitions; BC’s “Inventory Level = 0” filter shows products where any variant is zero. | Vortex IQ HIGHER count than BC product filter |
| MLI multi-location. We count “all locations zero”; BC product filter counts “any location zero” by default. | Vortex IQ LOWER count on MLI stores |
| Feed re-import settling. We apply a 5-minute settling window; BC shows the transient zero immediately. | Vortex IQ LOWER count during feed events |
Preorder / Backorder semantics. We exclude preorder items (is_preorder = true); BC includes them. | Vortex IQ LOWER on preorder-heavy stores |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
google_ads.ga_oos_disapproved | Google Merchant Center disapproves OOS items within 4-12 hours of detection | GMC has its own feed cycle; disapproval lag means the two cards don’t match exactly during fast-moving events. |
amazon_sp.amazon_buy_box_loss | Amazon buy-box loss often co-occurs with OOS spikes when Amazon is the affected channel | Amazon’s buy-box algorithm has more inputs than just stock; not all OOS events lose the box. |
klaviyo.kl_back_in_stock_capture | Each OOS event triggers back-in-stock email captures | Klaviyo’s capture form must be configured on the product page; if absent, captures lag. |
inventory_quantity transitions) and Adobe Commerce (per qty transitions); merchant-facing semantics are equivalent.
Known limitations / merchant FAQs
The alert fired right after my warehouse export ran. Was it a false positive? Probably yes, that’s the catalogue-feed-reimport pattern. Modern feed pipelines should batch-update inventory atomically, but many older integrations clear inventory before populating. The 5-minute settling window catches most of these; if your feed takes longer than 5 minutes to repopulate, configure the settling window to 10-15 minutes under Settings → Alerts → OOS spike → Settling. My alert fires every Tuesday morning. Why? Probably your weekly cycle-count or inventory adjustment runs Monday night. Cycle counts often produce momentary OOS as quantities zero before the new count writes. Either move the cycle count to a single atomic operation (preferred), or configure the alert to silence Monday 22:00 to Tuesday 06:00. Can I configure per-SKU sensitivity? Yes. High-velocity SKUs (your top 50) typically need an alert at any single-SKU OOS event; tail SKUs can wait. Configure per-SKU thresholds under Settings → Alerts → SKU sensitivity, or use the velocity-tiered preset (top 50 = single-SKU alert, tail = bulk-only). Why does this alert fire on inventory we never carried? Possibly a Channel Manager listing for a marketplace-only SKU that doesn’t exist in BC catalogue but has inventory tracked in Channel Manager. The alert sees the transition correctly. To suppress, mark the SKU astrack_inventory = false in BC, or configure Channel Manager to manage its own inventory.
My multi-storefront BC instance shares a catalogue across storefronts. Does the alert fire once or per-storefront?
Once, store-wide, because the inventory pool is shared. Per-storefront alerts only make sense if you have storefront-specific inventory (rare, and BC doesn’t natively support it without third-party extension).
Should I auto-hide listings or just alert?
Auto-hide on marketplaces (Amazon, eBay, Walmart, Facebook), alert-only on web. Marketplace algorithms penalise OOS-but-listed harshly; web theme can show “out of stock, restock notify” copy that captures email and converts on restock.
The OOS event was caused by an oversold SKU (Channel Manager kept selling after BC zeroed). What now?
Common BC pattern. Channel Manager’s marketplace listings can sell faster than BC’s inventory webhook propagates. The result: orders flow in for SKUs at zero stock. Configure Channel Manager → Inventory buffer to maintain a safety-stock margin (typically 2-5 units) below which marketplaces auto-hide; the buffer absorbs the propagation lag.
The alert says 6 SKUs but my products page shows 12 OOS. Which is right?
Both, different windows. The alert counts transitions in the last 60 minutes; the products page shows total currently-OOS regardless of when. The 6 in the alert plus 6 already OOS before the window started = 12 total. Pair with BC Channel OOS per Channel for the static count.
My B2B portal sells the same SKUs as DTC. Will an OOS event affect both?
Yes, by default both customer groups draw from the same inventory pool. If you want to reserve stock for B2B customers (common in industrial / wholesale), configure customer-group-specific inventory pools under Settings → Inventory → Customer group reservations. Then OOS-on-DTC won’t necessarily mean OOS-on-B2B.
Why exclude preorder items?
Because preorder items are intentionally OOS but available to purchase. Including them would flag every preorder launch as an alert. The exclusion uses the is_preorder flag and the preorder_release_date to determine state; if either is set, the item is treated as preorder, not OOS.