The worst time to learn a SKU is out of stock is when an order can’t ship. By then it has already reached a customer, and the reorder decision you needed to make was knowable days earlier. The number was sitting in your inventory the whole time. Nobody was watching it for you.

Shopify Flow can watch it for you. A basic alert takes about five minutes, and from there you can make it as smart as your operation needs. The three trigger-based recipes below run from simplest to most advanced, then a scheduled “days of inventory remaining” report, and finally an honest look at where Flow still hits a wall.

The 5-Minute Low-Stock Alert

Simplest. One threshold, all locations combined, fires in real time.

Shopify Flow uses a trigger, a condition, and an action: something happens, Flow checks a rule, Flow does something. For low stock:

Trigger: Product variant inventory quantity changed. Fires whenever a variant’s stock moves. (There’s also a Product variant out of stock trigger if you only care about hitting zero.)
Condition: Product variant / Inventory quantity is less than or equal to your threshold. 5 to 10 units is a fine starting point for a small catalog.
Action: Send internal email, or Send Slack message if your ops lives there. A nice extra: also Add product tag → reorder, so low items are filterable in admin.

That’s the whole workflow. Turn it on and you stop finding out about stockouts from a failed order. Import this version and you’re done in a minute:

Simple low-stock alert Shopify Flow template · .flow

Running more than one location? There’s an importable template for the multi-location version further down.

Access is easy: Flow is a free app on the Basic, Grow, Advanced, and Plus plans, so most stores already have it. A few advanced actions are reserved for higher tiers, but plain inventory alerts work on every plan that includes Flow.

One thing to file away for later: that Inventory quantity is the variant’s total across every location. For a single warehouse that’s exactly right. If you run more than one, skip ahead to per-warehouse alerts.

Set a Reorder Point That Isn’t a Guess

“Alert me at 10 units” is fine until a fast SKU sells 40 a day and a slow one sells 2 a week. A flat number alerts too late on one and too early on the other.

The threshold you actually want is a reorder point: the stock level where you need to reorder now to avoid running out before the new stock lands. The math is simple:

Reorder point = (daily sales velocity × supplier lead time in days) + safety stock

Say a SKU sells 8 units a day, your supplier takes 14 days to restock, and you want a 7-day buffer for surprises:

8 × 14 = 112 units used during the lead time
plus 8 × 7 = 56 units of safety stock
reorder point = 168 units

Set that SKU’s alert to fire at 168, not 10, and it arrives exactly when reordering still protects you. Weight your effort toward the items that hurt most when they run dry: a slow-to-restock product with a long supplier lead time, anything seasonal, anything where a stockout means lost sales you don’t get back.

One Alert for Every SKU (Per-SKU Reorder Points)

Intermediate. A different threshold for every SKU, still a single workflow.

Here’s the catch with reorder points: every SKU has a different one, and you don’t want fifty near-identical workflows. There’s a cleaner way. Store each SKU’s reorder point in a variant metafield (custom.reorder_point), then run one workflow that checks each variant against its own number.

Add a number metafield custom.reorder_point to your variants and fill in each SKU’s value (use the reorder-point math above).
Trigger: a variant’s inventory quantity changes.
A short code step reads the variant’s current stock and its custom.reorder_point, then decides whether to alert.
Action: email you when a SKU is at or below its reorder point.

One workflow covers your whole catalog, each SKU judged against its own number. You keep the metafield current with a bulk edit or a script that runs the velocity math above.

We built a couple of safeguards into the template. The code step quietly ignores any variant that doesn’t have a reorder point set, so a missing or non-numeric value never errors or false-alarms. And it uses a second, self-managed metafield (custom.reorder_alerted) to remember it already warned you: you get one alert when a SKU first dips below its point, silence while it stays low, and a fresh alert only after you restock above the point and it dips again. No repeat spam, and a SKU that’s already low when you switch it on still gets caught. (It sets that flag through Flow’s admin action, so allow Flow to update metafields when you import it.)

Per-Warehouse Alerts (Multiple Locations)

Advanced. Alert on a specific location’s stock instead of the combined total.

The moment your inventory lives in more than one place, the simple alert gets blunt: the variant total can read healthy while the warehouse that actually serves a region is nearly empty.

This is where people hit a well-known wall. The inventory trigger reports the prior quantity for the variant across all locations, not per location, and if you try to filter by Location / Name, Flow tends to return every activated location as one comma-separated string, so a condition like “only the East Coast warehouse” reads as true for everything. Merchants running two warehouses keep tripping over exactly this.

The fix is to stop interrogating the change event’s location list and read each location’s number directly. Two ways, depending on whether you want a scheduled sweep or a real-time guard.

Option 1 — a daily per-warehouse sweep. On a schedule, loop your products and check each variant’s stock at the location you care about, then email the thin ones. That’s exactly what the template below does: Scheduled time → fetch products → check that location’s inventory level → email.

Option 2 — a real-time per-location guard. If you need the alert the instant stock drops, keep the Product variant inventory quantity changed trigger, then add a Get data step that reads that specific location’s live inventory level and condition on it. More setup, and it leans on Flow’s data step rather than a no-code action, but it fires immediately and checks only the SKU that moved.

One rule of thumb that saves real frustration: match the location on its ID, not its name. IDs are unique, and matching the name against the trigger’s location list is what produces the “always true” bug above.

Want a head start? Import this into your store under Flow → Import, then point it at your location and email.

It’s a scheduled sweep: once a day it loops your active, inventory-tracked products and emails you any variant that’s at or below your threshold at one location, with a full per-location breakdown. After importing, set two things to your store: the location name (it has to be your exact Shopify location name, or the condition matches nothing) and the alert email. One limit to know going in: it checks up to 100 products per run, so a larger catalog needs pagination.

A Scheduled Days-of-Inventory Report

A different shape: not a trigger, but Shopify’s own days-of-cover numbers on a schedule.

The three recipes above all fire on a unit threshold. But the number you might actually want is days of inventory remaining, and Flow can’t trigger on it. What it can do is read it on a schedule, using the Get analytics data action and Shopify’s own report.

This rides on Shopify’s native “days of inventory remaining” report, so the numbers match what you see in Analytics. We just filter to the SKUs about to run out and drop the chart formatting:

Trigger: Scheduled time (e.g. daily).

Action: Get analytics data, with this ShopifyQL query:

FROM inventory
  SHOW ending_inventory_units, inventory_units_sold_per_day, days_of_inventory_remaining
  WHERE inventory_is_tracked = true
  GROUP BY product_title, product_variant_title, product_variant_sku
  HAVING inventory_units_sold_per_day > 0 AND days_of_inventory_remaining <= 14
  SINCE startOfDay(-30d) UNTIL today
  ORDER BY days_of_inventory_remaining ASC

Action: email the rows, or send them to Slack.

The <= 14 is your alert threshold: set it to your reorder lead time, so you’re warned with just enough days left to restock. The -30d is the sales window Shopify averages to estimate the daily burn rate. (If the editor balks at the line breaks when you build it, paste the query as one line.)

Honest caveat: days of inventory remaining is a trailing 30-day average, so it’s smoothed and a little lagging. Great for steady sellers; rough for seasonal or spiky SKUs, because it won’t see a surge coming and a recent spike understates the real burn rate. And it’s a scheduled report, not a live trigger. For real-time, the per-SKU reorder point above is the move.

Want it ready-made? Import this and set your email — it only sends on days something’s actually low.

Where Flow Still Stops

Even with all of the above, Flow is one store at a time. It watches the inventory inside your Shopify admin. The harder question, once stock is spread across multiple warehouses or 3PLs, isn’t “did one number drop in one place” but “across every provider holding my inventory, where am I about to come up short, and what do I fix first?” The per-warehouse workaround answers it for two locations. It stops scaling around the time you’re running four.

When You Outgrow Per-Store Alerts

That bigger question is the one 3PL Pulse exists to answer. We’re the independent layer that sits above your fulfillment providers and reads what’s really happening across all of them, instead of taking each system’s word for it. Today that shows up most in your orders: we catch the stuck, late, and broken ones before a customer does. Inventory is the same problem from a different angle, and a natural next thing for a layer that already sees across providers.

So set up the Flow alert. It’s the right first move and it’ll save you real money. And if you’re running stock across more than one provider, where a single per-store threshold stops being enough, that’s exactly the corner of fulfillment we’re leaning into next. Tell us how you handle it today or start tracking your fulfillment — the brands who talk to us early are the ones who shape what comes next.

FAQ

Does the low-stock condition check total stock or stock at one location?

By default, total. Product variant / Inventory quantity is the variant’s available quantity summed across every location. Perfect for one warehouse, misleading when stock is split. See per-warehouse alerts for the multi-location build.

Why does my location-specific condition fire for every location?

Because matching on Location / Name tends to return all of your activated locations as one comma-separated string, so the check reads true no matter which location changed. Match on Location / ID instead, and read the quantity from that same inventory level. Better still, fetch the location’s number directly rather than filtering the change event’s list.

Is there a per-location or “inventory item changed” trigger?

Not for quantities. The only quantity-change trigger is Product variant inventory quantity changed, and it’s aggregated across locations. Inventory item created and Inventory item deleted exist, but those are about the tracking record, not stock levels. Newer Inventory transfer triggers cover stock moving between locations.

Can Flow alert on days of inventory remaining?

Not as a trigger, but yes as a scheduled report. There’s no native trigger for “days of cover,” but Flow’s Get analytics data action can run Shopify’s own days-of-inventory query on a schedule — see A Scheduled Days-of-Inventory Report above for the exact query. It’s a trailing 30-day average, so treat it as a rough lens on fast or seasonal SKUs, and use the per-SKU reorder point for a real-time line.

How to Set Up Low-Stock Alerts in Shopify Flow