Shopify low stock alerts: the threshold that works

A low stock alert is only useful if it fires early enough to place an order. That sounds obvious, and it is the exact thing most stores get wrong: a threshold set at "10 units" on a product selling 6 a day with a 40-day supplier fires with under two days of cover left — a notification that arrives 38 days after the decision needed to be made. The alert worked. The threshold failed.

This guide separates the three questions that get bundled together: what Shopify will alert you to natively (as of November 2026), how to build a real alert with Flow or an app, and how to compute a threshold that turns "stock is low" into "order on Thursday." It also draws the line this article doesn't cross — alerts tell you about your stock, while badges tell shoppers about it, which is a different discipline entirely.

What the native admin gives you

Three mechanisms exist, and none of them is quite "low stock alerts" the way merchants picture it:

Saved views on the Inventory page. Products → Inventory supports filtering by available quantity, sorting ascending, and saving the result as a named view. "Available ≤ 10" is one filter and a save away. It is accurate, free, and completely passive: it only works if someone opens it, and the week you need it is the week nobody does.

Shopify Flow. Included on paid plans at the time of writing, Flow can send real notifications. The pieces that matter: the Product variant out of stock trigger, the Send internal email action, and a template library that includes low-inventory email workflows and daily out-of-stock summaries. Flow can also post to Slack via its app actions. What Flow cannot do natively is compare a quantity to a per-variant threshold you maintain centrally — thresholds live inside workflows, so a catalog-wide system becomes one workflow per threshold band, which is workable at 50 SKUs and tedious at 500.

Notifications settings. Worth checking once so you know what is not there: Settings → Notifications covers customer, staff, and webhook notifications. There is no per-variant "email me under N units" setting in the core admin as of November 2026 — verify it in your own store in under a minute rather than trusting a blog post, including this one.

What alert apps add

The app category exists to fix two specific native weaknesses: per-variant thresholds, and push delivery where you will actually see it. Typical capabilities across the category are threshold rules per variant or product, delivery by email, SMS, or Slack, and scheduled digest reports rather than one alert per event. Prices in the accessible end of the category run from free tiers to roughly $20–30/month at the time of writing; read the listing carefully, because several "low stock alert" apps are primarily storefront badge tools with an email feature attached.

Buy one for the delivery mechanism, not for the thinking. No alert app knows your supplier's lead time unless you tell it, which brings us to the actual work.

The threshold problem, worked

Cover is the only number that makes an alert meaningful: units on hand divided by daily velocity. An alert is early if cover at the moment it fires exceeds your lead time. It is late otherwise.

A store selling a cosmetic brush at 6 units a day, ordering from a supplier with a 40-day lead time, running a threshold of 10 units:

• Cover when the alert fires: 10 ÷ 6 = 1.7 days
• Cover the lead time requires: 40 days
• Shortfall: 38.3 days — the alert is late by more than five weeks

To never go dark with that supplier, the reorder has to fire at 6 × 40 = 240 units, plus a buffer. Two weeks before the 10-unit alert — at 94 units — the store still had only 15.7 days of cover, 24 days short of what the supplier needs. The merchant followed the alert faithfully and still went dark, which is how stores conclude that "alerts don't work" when the alert was never the problem.

The fix is the reorder point formula, applied as an alert threshold:

Alert threshold = (daily velocity × lead time in days) + safety stock

With a 25% buffer on lead-time demand (a defensible starting point for an unreliable supplier, generous for a dependable one): 240 + 60 = 300 units. When stock touches 300, you order. If the supplier is on time, the PO lands with the buffer still standing; if they slip two weeks, the buffer absorbs it. The full derivation, including how to size the buffer deliberately, is in the reorder point formula and the safety stock method.

Two honest consequences of doing this arithmetic:

• 300 units will look absurd next to a threshold of 10. That is not a bug; it is what a 40-day supply chain costs. The right responses are larger, less frequent orders or a faster supplier — not lowering the threshold back to something that feels comfortable.
• Velocity must exclude out-of-stock days. If your daily average includes weeks when the SKU was dark, the formula under-orders silently, and your alerts are late in a way no threshold can fix.

Turning one threshold into a catalog

A single threshold per SKU is the correct unit of analysis, which means the real work is maintaining a few hundred of them:

1. Compute per SKU, not per category. A brush at 6/day and a candle at 0.4/day share the same 40-day supplier and need thresholds 15× apart.
2. Store the inputs, not just the answer. Keep velocity and lead time as columns and let the threshold be a formula, so a lead-time change updates every affected SKU instead of stranding stale numbers.
3. Re-derive quarterly. Lead times drift, velocities shift with seasonality, and a threshold computed in spring against a supplier who has since slowed is wrong without ever announcing it.
4. Escalate by dollars, not units. A threshold breach on a $4 item and a $90 item are not the same event; the alert queue should be ordered by what being dark would cost, which is price × in-stock velocity × expected dark days.

That fourth rule is where most alert systems quietly fail: they deliver a flat list, the list is long, and the important line scrolls away. Ranking by exposure is a design decision, not a feature.

What alerts don't do

Three gaps worth naming, because each has a different fix:

• They don't price the miss. An alert says "12 left." It doesn't say that being dark for a week on this SKU costs about $1,200 in demand you cannot recover, some of which goes to a competitor permanently.
• They don't survive a skipped Monday. A digest in an inbox you don't open on a busy week is the same as no digest, so delivery channel matters more than alert volume.
• They don't stop you overselling. Alerts are about the future; overselling is about the present. Negative stock, sync lag, and "continue selling when out of stock" are a separate problem with a separate fix.

And one adjacent thing that is not an alert: showing low stock to shoppers. Storefront badges are a merchandising decision with their own honesty requirements and their own failure modes, covered in the Shopify low stock badges guide. Never let a badge tool be your source of truth about whether to reorder.

A setup order that works

Start narrow and let the system earn its coverage:

1. This week: compute thresholds for your ten fastest-selling SKUs from velocity × lead time + buffer, and write them somewhere you look at daily — a saved Inventory view sorted ascending, a spreadsheet tab, or a Flow workflow per band.
2. This month: add the dollars-at-stake column so the list ranks itself, and move delivery to wherever your team actually reads (Slack beats email in most small teams).
3. This quarter: extend to every SKU with a lead time over 21 days, since long lead times are where late alerts cost the most, and re-derive the inputs rather than the thresholds.

That sequence produces a system slightly less automated than a fully loaded app and considerably more likely to be maintained. The app version, for what it's worth, is where our own roadmap points: InventoryX is in development as the planning layer that carries per-SKU velocity, lead times, and reorder quantities into a weekly buying list — it is not a live app today, and ClearStock, our live one, focuses on discounting slow stock rather than alerting.

Common questions

Does Shopify have a low stock alert? Not a per-variant threshold email in the core admin as of November 2026. You get filterable and savable Inventory views, Shopify Flow triggers and email/Slack actions, and notification settings that cover customers, staff, and webhooks. Build the threshold alert with Flow or an app, and verify the current state in your own admin.

How do I set up a free low stock alert in Shopify? With Shopify Flow on a paid plan: use an inventory trigger with the Send internal email action, or adapt one of Flow's low-inventory templates. Budget half an hour for the first workflow and expect one workflow per threshold band, since thresholds live inside the automation rather than in a settings table.

What's a good low stock threshold? Daily velocity × supplier lead time in days, plus safety stock. A product selling 6 a day with a 40-day lead time needs its reorder to fire around 240 units plus buffer — not at 10 units, which fires with 1.7 days of cover and guarantees a stockout.

Why do my stock alerts fire too late? Because the threshold measures "feels low" rather than "time to reorder." Any threshold below daily velocity × lead time is mathematically guaranteed to fire after the last safe ordering day, whatever the alert channel or app.

Should I use a different threshold for each product? Yes. Velocity and lead time vary per SKU, and a single storewide number is right for at most one product by coincidence. Store velocity and lead time as inputs and compute the threshold, so changes propagate instead of silently invalidating last quarter's number.

Next step

Take your ten fastest sellers and test each one's current alert threshold against velocity × lead time + 25%. Any SKU whose threshold sits below its lead-time demand is one supplier delay away from the brush example — late before the alert ever fires. Fix those ten first; the rest of the catalog can wait a quarter, but those ten cannot.