Low stock notifications in Shopify: the three routes

There is no switch in the Shopify admin that emails you when a variant drops below a number. The inventory pages show and adjust quantities. Shopify Flow, Shopify's own automation app, is the tool Shopify points merchants at for acting automatically on an inventory change. The page in this pillar on what Shopify has built in covers that ground properly, so this page stays on the choice between routes.

There are three of them. Listed here in rising order of setup effort, and falling order of ongoing manual work.

• Watch it yourself. Filter the inventory list, sort by quantity available, and give yourself a standing reminder. Costs nothing. Only as reliable as your week.
• Build a Shopify Flow workflow. A trigger on inventory change, a condition on quantity, an action that emails you. It fires without you remembering.
• Run a reorder-alert app. The threshold is calculated per SKU from how fast that SKU sells and how long your supplier takes. The alert lands when the SKU crosses it.

Most small catalogues start at route one and move to route two. Then they hit the wall every fixed threshold hits. One number cannot describe a catalogue where one product sells forty a day and another sells one a fortnight.

Check Shopify's current help pages, linked at the foot of this guide, before you build anything. Admin screens move.

Be clear about the event before you build the alert. "Low stock" is not one thing. It is three.

Quantity crossed a number. Easy to detect. Easy to get wrong. Set 10 across the store and your hero SKU is already lost by the time the message arrives, while your slow mover emails you eleven months early.

Cover ran short. The number here is days of stock left at the current rate of sale. Twelve units is three weeks of cover on one product and two days on another.

Reorder point crossed. This is the useful one. The reorder point is the level at which you must place the order today for stock to land before the shelf empties. It is built from two inputs: how fast the SKU sells, and how long your supplier takes.

Routes one and two can only see quantity. Route three is the only one that watches cover and reorder points. Settle this first. It decides the whole build.

A low stock workflow in Flow has three parts. A trigger on an inventory change, a condition on the quantity available, and an action that sends an internal email or posts to Slack. Availability of Flow depends on your Shopify plan, so confirm that in Shopify's own documentation first. Shopify's reference for the inventory quantity changed trigger also hands you the previous quantity, which is worth using in the condition so the workflow fires on the crossing rather than on every unit sold below the line. Test the finished workflow by adjusting one variant below your threshold and watching the message arrive, then set the quantity back.

It runs out of road in predictable places. One workflow holds one fixed number, so a catalogue of mixed speeds needs several. The number you set in February does not move when a product doubles its rate in November. Flow knows your stock level, not that this supplier takes twenty-one days and that one takes four. And alerts arrive as a stream, when what you want on Monday is one list.

The page in this pillar on what Flow can and cannot do walks the build and the limits step by step.

An app takes the arithmetic off you. The shape of the setup is the same whichever app you pick.

• Connect the store. You install through Shopify's OAuth flow, which grants read access to products, inventory levels and orders. Restoc can also take an Admin API access token pasted from a custom app. The install reads your current inventory levels and backfills the last 30 days of sales, so the velocity figures are not starting from zero on the day you connect, then webhooks plus a scheduled sync job keep both current.
• Set a lead time. This is your number, not Shopify's. Nothing in your store data knows how long your supplier takes. Restoc takes it per SKU on the reorder rules screen, or once per supplier: it syncs each SKU's Shopify vendor, and a vendor lead times screen lists every distinct vendor in your catalogue, so one number covers every SKU under that vendor that has no lead time of its own. You are not typing a figure into hundreds of rows before the first reorder point is right.
• Pick the window the sales rate is averaged over. In Restoc that window is 7, 14 or 30 days and it is set store-wide, with a per-SKU override on the Pro plan for the lines that need their own.
• Choose where the message lands. Email on every Restoc plan. Slack, through an incoming webhook alongside email, from Growth upwards. There is a page in this pillar that walks the Slack webhook step by step, and one on putting reorder alerts in the channel your team already watches.

The reorder point is then recalculated from those two inputs rather than sitting where you left it, and the alert fires on the crossing. One crossing, one message: Restoc's alert job will not send the same alert twice if it runs again, which has its own page here. That matters more than it sounds. The fastest way to kill an alert channel is to repeat yourself.

The dashboard shows current stock, days of inventory remaining and reorder status per SKU. It opens soonest to stock out first and sorts on that column, so the lines closest to running out are read in one pass rather than hunted for, and the vendor sits on the row, on the dashboard and on the weekly report, so a reorder list can be worked supplier by supplier. Recent alerts are listed on the dashboard too, each with when it was triggered and when it was delivered. Two things we would rather you heard here than found on a Monday: that panel shows the most recent crossings, not the full history across a 60-day trial, and the weekly report is still ordered by product title rather than by urgency. Both are on our list, and we will change this page when they change.

Two setup details decide whether you trust the output. Use the full time from placing an order to the stock being sellable, including customs and putting away, and round up. Then check one product you know well against your own judgement before you accept the rest. If they disagree, the lead time is usually the thing that is wrong.

There is a page in this pillar on whether an app is the right answer at all, one on how the store connection works and what it reads, and feature pages on reorder points, days of inventory remaining, sorting by days of stock left, the email alert itself, and the weekly reorder report.

Whichever route you pick, the threshold is the decision that matters. The shape is simple. Average units sold per day, multiplied by supplier lead time in days, plus a buffer for the days you sell above average. That total is your reorder point.

Two choices sit inside it. The lookback window you average the daily rate over, 7, 14 or 30 days, and how much buffer you add for variability in demand and in your supplier. Both are real decisions with real trade-offs, and the feature page on reorder points works through them with an example. A short window follows a trend quickly and overreacts to one big order. A long window is steadier and slower to notice a product taking off. If your supplier has slipped by a week twice this year, put that slip in the lead time rather than hoping the buffer absorbs it.

Slow sellers are where a round number does the most damage. A product that sells one unit every ten days against a three-week lead time needs a reorder point of about two, so a store-wide threshold of ten fires months early and trains you to ignore the channel.

Alert systems fail in one of two directions. Both end with a merchant ignoring them.

Too loud. Thresholds set too high, or a change trigger firing on every small movement. Within a fortnight the channel is muted. Fix it at the source. Raise the bar for what deserves a message, and keep the long tail in a weekly list instead.

Too quiet. Thresholds built on an out of date sales rate, or lead times entered optimistically. This one is worse. Nothing looks wrong until a bestseller hits zero. Audit it deliberately. Each month, take the three SKUs that came closest to running out, and check whether their reorder point would have given you enough time.

A few habits keep the signal clean.

• Separate the products you would reorder from the ones you would let sell through. Only alert on the first group.
• Keep seasonal lines on a shorter velocity window while they ramp, then move them back.
• When a supplier misses a promised date, update the lead time that day, while you are annoyed enough to remember. If the slip applies to everything that supplier ships, change it once at the supplier level rather than SKU by SKU.
• Give one person the job of acting on the alert. Shared responsibility for a notification means no responsibility.
• Check that the alert was actually delivered, not just triggered. A message that sat unsent is the same as no message, and there is a page here on the four things to check when nothing arrived.
• Review whether the threshold caught the problem, not just whether the email arrived. Delivery is not the outcome you want.

Running out of stock on a line that sells is a real hit, and a quiet one. No refund request, no complaint. Just a day where the money does not arrive. Treat the monthly audit as part of the job, not admin.

Run through this once, whichever route you chose. Ten minutes. It is the difference between an alert system and an inbox filter.

• You know which event you are detecting: quantity crossed, cover ran short, or reorder point crossed.
• Every SKU you would reorder has a lead time you would defend to your accountant, whether you set it on the SKU or on its supplier.
• The sales rate behind your threshold is recent, and you know how recent.
• The products you would not reorder are excluded from the alert.
• The message carries the SKU code and the quantity remaining, so it can be acted on without opening the admin.
• A named person receives it and knows what to do next.
• You have sent a test alert down the channel you intend to rely on, and seen it land. The page here on testing an alert covers that for Slack webhooks in particular.
• There is a date in the calendar to review the thresholds, not a vague intention.

If you only get four done, do the lead times, the exclusions, the named owner, and the test. Those four carry most of the value.