The Quality of an Alert Is Decided Before It Is Sent
"I got the same restock email three times." "I opened the alert and the item was already sold out." Those are the two complaints that come up about restock notifications, and rewriting the email copy fixes neither of them. The cause sits one step earlier, in the part that decides stock has come back.
This article works through how to spot the moment inventory returns, and how precisely those rules need to be defined. To be clear, this system hasn't been built yet. Read it as a design note written down before starting, so the decisions are on record. Detection feeds every stage that follows, so leaving it vague means spending the rest of the project patching over the gaps in delivery and in the admin screen.
Trigger Only on the Moment Stock Returns From Zero
"Stock exists" as a trigger sends the same alert repeatedly
If the trigger for sending is simply "there is stock," the condition is satisfied every single time you look. An item that goes from ten units to nine still qualifies as "in stock," so it gets picked up as a candidate at every check, and the same person receives the same message again and again.
So narrow the trigger to a single event: an item that had zero stock now has stock. Last time it was zero, this time it is one or more. Only that change makes it a candidate. Tightening one condition removes almost every duplicate-send complaint. Fixing this axis before you start building is the easiest decision you'll make.
Judge by color and size, not by product
Inventory moves independently for each color and size of the same product. Decide at the product level and someone waiting for a medium will get an alert triggered by a large coming back in. From their side, that reads as "you told me it was available, and it isn't."
So the unit of judgment should match the unit people actually choose and buy — each color, size, or other option. If sign-ups are captured at that same level, matching inventory changes against the people waiting stays straightforward too.
Retrieve the count you recorded the last time you checked
Take the current count from the Shopify notification, or by checking again
Treat it as a candidate only if it was zero before and is one or more now
Only confirmed candidates get lined up for delivery
The point of the diagram is one thing: don't look at the current stock level alone. Compare it against the previous count, and move forward only when the change from zero has actually happened.
Settle the Ambiguous Cases Before You Build
Do you send when only one unit comes back?
Whether a single returning unit is worth an alert is exactly the kind of thing that splits opinion once the feature is live. Send on one unit and plenty of people get the message while only the first one can buy. Wait until several are in stock and fewer people hear about it — but fewer people are disappointed too.
There is no universally right answer; it depends on what you sell. High-priced items that rarely restock might justify sending on a single unit, while routinely replenished items can wait for a few. What matters is writing this rule down before implementation, not after.
What to do when it sells out again immediately
If stock returns and sells out five minutes later, do the alerts already queued still go out, or do they stop? That decision needs to be made too. Send them and people open an alert for a sold-out item; stop them and you get "it restocked and nobody told me."
Checking stock once more right before sending, and holding the message if it has fallen back to zero, at least avoids advertising something nobody can buy. Decide at the same time whether held messages resume when stock returns again.
Make Sure the Same Alert Never Goes Out Twice
Assume inventory notifications will arrive more than once
The webhook that reports inventory changes (a mechanism that automatically sends word when something happens) can deliver the same message twice, thanks to network delays or retries on the sending side. Build on the assumption that it arrives exactly once, and you'll send two alerts for one restock.
The fix is to give each incoming notification an identifier and keep a record of the ones already handled. If a notification with the same identifier arrives again, finish without doing anything. In other words, running the process twice produces the same result as running it once. Reliability is settled here, well before anyone edits the email copy.
Why you keep your own record of previous stock levels
Relying on incoming notifications alone leads to wrong calls when they arrive out of order. If "now one unit" lands before "now zero," you're not processing events in sequence, and the change can't be read correctly.
So keep your own record of how much stock existed and when, and compare against it. The number the decision was based on stays on hand, which means you can explain later why a particular alert went out. Being able to look that up when a question arrives turns out to matter a great deal once the feature is in daily use.
Wait a Few Minutes, Then Check Again
Handling items whose stock bounces around
Right after a restock, inventory counts often move up and down over a short window — receiving is entered in batches, a cancellation temporarily returns a unit, and so on. Send an alert in the middle of that churn and there's a good chance the stock is gone by the time it lands.
So don't send the moment you spot the change. Wait a few minutes, check inventory again, and only queue the alert if stock is still there. If it is back to zero, skip it. The alert arrives a few minutes later, and far fewer people open a message for something they can't buy.
Fast, but items with fluctuating stock often lead to "sold out by the time I opened it"
A few minutes slower, but the item is far more likely to still be buyable on arrival
A short pause and a second look is enough to cut down significantly on alerts that arrive for something already gone.
Detection doesn't need contact details
The part that decides whether stock has returned has no use for email addresses. All it needs is which product, which option, and when it went from zero to available. Contact details only come into play once you start deciding who to send to.
Limiting the data each layer touches means fewer places where personal information sits, and fewer moments where investigating an issue puts it in front of someone. Operational records shouldn't carry raw contact details either — keep them traceable with partially masked identifiers instead. That policy belongs in this design step, alongside the detection rules.
Summary
What's worth having at this stage isn't working code but an agreed set of rules for avoiding wrong alerts. Trigger only on the return from zero, discard duplicate notifications, wait a few minutes and re-check, and keep the data handled to a minimum. Settle those four and you avoid major rework when the delivery pipeline and the admin screen get built.
How those decisions carry through into delivery is covered in the next two articles.
Notification Delivery Pipeline Design (Queue, Throttling, Retry)
Building delivery around a pending send list, pacing the sends, and handling retries after failures.
Back in Stock Admin UI Implementation Guide
Screen design for checking, retrying, and adjusting settings that an operations team can live with daily.