OOS variants. Pair with the cross-channel ad-spend card to find the real revenue blockers.
At a glance
Real-time count of variants with inventory_quantity <= 0 while still being marketed. The most actionable inventory pulse on the dashboard, every variant on this list that is also part of an active ad campaign is burning ad spend with zero conversion possibility.
| What it counts | COUNT(variants WHERE inventory_quantity <= 0 AND track_quantity = true AND product.status = 'active'). Counts variants, not products; a 5-variant product with 1 OOS counts as 1. |
| API endpoint | GET /v1/products/inventory_levels polled every 15 minutes; webhook updates fire on inventory_levels.update. |
| Negative quantities | Negative values (oversold) count toward this number. Shopline allows negative inventory by design for backorder flows; the card surfaces them as the most urgent sub-set. |
| Active products only | Variants on draft, archived, or hidden products are excluded. Hidden-from-storefront-but-buyable-via-direct-link variants are included (they can still be ordered). |
| Multi-warehouse | Counts a variant as OOS only if total quantity across all warehouses is <=0. A variant with 0 in HK and 50 in TW shows as 50 (in stock). Merchants can configure per-warehouse view in Nerve Centre settings. |
| Pre-orders | Backorder-enabled variants (continue_selling_when_out_of_stock = true) are excluded; they are intentionally OOS and still selling. |
| Currency | Not relevant; this is a count. |
| Channel scope | All variants regardless of which channel (storefront, POS, social-commerce app) they are surfaced on. Granular channel-aware OOS is a separate roll-up. |
| Time window | RT (real-time, 15-minute polling, webhook-instant). |
| Alert trigger | >0. The hero-tier threshold reflects “any OOS variant with active marketing is an immediate revenue blocker”; can be relaxed in manifest config for catalogue-heavy merchants who tolerate some baseline OOS. |
| Sentiment | out_of_stock_count. Inverse gauge. |
| Roles | owner, operations. |
Calculation
Calculated automatically from your Shopline data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
An APAC fashion brand running a Hong Kong Shopline store, snapshot at 09:30 HKT on 27 Apr 26. The brand sells womenswear with sizes XS-XL. Total catalogue: 1,200 SKUs (240 products x ~5 size variants each). At snapshot time the OOS-variant count reads 47.| Reason | Count | What it means |
|---|---|---|
| Hero SKU XS / S sold out (popular sizes) | 22 | Sunday traffic cleared the shelves on best-sellers |
| Slow seasonal SKUs that were never well-stocked | 14 | Background OOS, low priority |
| Negative-stock variants (oversold over weekend) | 4 | Sync issue with warehouse 2; immediate fix needed |
| Backorder enabled but flagged as OOS due to misconfig | 7 | The merchant intends to backorder but continue_selling_when_out_of_stock is false |
shopline_xc_ads_on_oos drill-down at work.
The 4 negative-stock variants are the urgent ones; orders accepted against negative inventory will eventually fail to ship and convert directly into refund-rate spikes. The merchant should pause those listings now and reconcile inventory with warehouse 2 before re-enabling.
The action: pause ads for the 18 ad-active OOS variants today (saves HK$ 2,140 / day), pause sales on the 4 negative-stock variants until reconciled, and add the 22 hero-XS/S variants to a restock-priority email list. Total OOS count should drop from 47 to ~25 after restock arrives later this week.
Sibling cards merchants should reference together
| Card | Why it matters next to OOS count | What the combination tells you |
|---|---|---|
| Active Ads on OOS SKUs | The kill-shot pairing. | OOS count + ads-on-OOS = ad spend you can pause today with zero revenue downside. |
| Low-Stock SKUs (<10 units) | Restock-window window. | Predicts which variants will hit the OOS card next; allows pre-emptive restock. |
| Days-of-Cover by SKU | Velocity-aware stockout risk. | OOS today is a fact; days-of-cover predicts tomorrow. |
| Top Products by Revenue | Cross-reference for revenue impact. | OOS on a top-10 SKU has 10x the revenue impact of OOS on a tail SKU. |
| OOS Spike Alert | Real-time anomaly. | Catches sudden OOS spikes (sync issue, viral demand, bot-buying). |
| Total Revenue | The downstream. | Persistent OOS on hero SKUs is the most-common cause of revenue dropping while traffic is flat. |
| Refund Rate | Negative-stock downstream. | Orders accepted against negative inventory eventually refund; OOS-with-orders is a refund-rate leading indicator. |
| Shopline Health Score | Composite. | OOS count is a heavily weighted health-score input. |
Reconciling against the vendor’s own dashboard
Where to look in Shopline’s own dashboard:
Shopline Admin -> Inventory -> Variants (filter by inventory_quantity <= 0)
The Admin view is real-time; the count there should match this card within sync-lag tolerance.
Why our number may legitimately differ from Shopline’s Admin:
| Reason | Direction | Why |
|---|---|---|
| Sync lag | Ours occasionally higher | Webhook-driven; under 60s typically. Recent stock receipts may not be reflected for a few minutes. |
| Backorder handling | Ours lower | We exclude continue_selling_when_out_of_stock = true variants; Shopline Admin shows them. |
| Multi-warehouse aggregation | Marginal | We sum across all warehouses; Shopline Admin can be filtered by warehouse, which a merchant doing a manual count may forget. |
| Draft / archived products | Ours lower | We exclude variants on non-active products; the Admin filter does not always do this by default. |
| Hidden from storefront | Ours higher | We include hidden-but-buyable variants; the Admin storefront filter excludes them. |
shopline_inventory_alerts = COUNT(variants WHERE inventory_quantity <= 0 AND track_quantity AND product.status = 'active' AND NOT continue_selling_when_out_of_stock) evaluated in real-time.
Known limitations / merchant FAQs
Why is the alert at any non-zero count? Because every OOS variant with active marketing is a revenue blocker. The alert is meant to be loud; if the merchant runs a large catalogue and tolerates some baseline OOS, the threshold is configurable per-store. My count includes negative-stock variants. Is that a bug? No, that is intentional. Negative stock means “we accepted more orders than we have inventory for”; those orders will fail to ship and convert to refunds. Surfacing them prominently is the point. Why doesn’t this match my warehouse stock report? Two usual causes. (1) Shopline only knows what was synced to it; if your warehouse system pushes updates on a 4-hour cadence, the Shopline view lags. (2) The card excludes backorder-enabled variants by design; your warehouse report may include them. My OOS count never drops below 30. Why? Almost always tail SKUs the merchant has long-term ignored. The healthy action is to either restock or archive them. Tail OOS pollutes the count and de-sensitises the alert; archiving cleans both. Can I exclude specific variants from the count? Yes; tag themvortexiq_ignore_oos (or set the manifest exclusion list). Use this for end-of-line clearance variants where you do not intend to restock and do not want the alert noise.
My ads card shows 18 ads on OOS but this card shows 47 OOS variants. Why the gap?
The 18 are OOS variants that are also on active ad campaigns; the other 29 are OOS but not currently being advertised. Both are blockers, but the ads-on-OOS subset is the highest-ROI pause action because you save spend immediately.
How fast does this update after a restock?
Webhook-driven; under 60 seconds in practice. The merchant updates inventory in the Shopline Admin or via API, the webhook fires, and the count drops on the next render.
Does this count product-level or variant-level OOS?
Variant-level. A product with 5 variants where only the XS is OOS counts as 1, not 5. This matches how merchants think about OOS (per-size, per-colour, per-variant).
Why doesn’t this surface my JKO / FPS payment OOS issues?
This card is inventory only, not payment. Payment-method outages show up in shopline_payment_methods as a sudden share drop and in shopline_alert_revenue_drop as a revenue anomaly.