I measured how much warning my stock alerts actually gave me. Two days.

For ten weeks this year I kept every reorder alert my inventory system sent me instead of actioning them and moving on. 37 alerts between May 7 and July 19. Then I sat down one Sunday with our out-of-stock history and lined them up: the date each alert fired against the date the SKU actually ran out.

The median gap was 2 days.

Two days of warning, on SKUs where our domestic suppliers run 10 to 14 business days. And 51 percent of the alerted SKUs went on to stock out anyway. These weren't early warnings. They were announcements.

Why I bothered measuring

I run Personalised Favours, a Sydney-based manufacturer on Cin7 Core. Our catalog runs to tens of thousands of SKUs; the core we actively manage sits in Stocura, where we're the founding customer. Being the founding customer means that when something smells wrong, I get to say so directly and expect it fixed.

Something smelled wrong. We kept stocking out of SKUs that had already alerted. SKUs the system flagged, that I saw flagged, that ran out regardless. Either I was too slow to act, or the alerts fired too late for acting to matter. I wanted to know which.

The answer turned out to be both. I'll get to the uncomfortable half at the end.

The alert and the reorder math were two different numbers

Here's what the measurement surfaced. The reorder queue, the screen that decides which SKUs need a purchase order this week, was doing the full calculation: demand over the supplier's learned lead time, seasonal adjustment, buffer stock. The alert email was running a simpler version of the same job. Two thresholds doing one job. The queue would move a SKU into "Order Now" and the email would stay quiet for another week or two until the simpler math finally tripped. By then the runway was gone.

The same failure shows up anywhere the number that triggers your notification differs from the number that drives your reorder decision. Cin7 Core's own low-stock notification fires on the static reorder point you typed in at setup. If you set that number two years ago from a flat 12-month average, your notification threshold has been drifting away from your actual demand ever since, while the emails kept arriving with a confident subject line.

An alert threshold has exactly one job: fire at the last moment you can order and still receive stock before you run out. That moment has a formula.

Alert point = (daily demand × supplier lead time, in calendar days) + buffer stock

Put numbers on it. A SKU selling 6 units a day, from a supplier averaging 12 business days. Twelve business days is roughly 16 calendar days, so lead-time demand is 96 units. Add a 20-unit buffer and the alert should fire at 116 units.

Now suppose your notification threshold is set at 40 units, because someone typed 40 in during onboarding three years ago and demand has grown since. The alert fires with 40 units on the shelf and a 16-day resupply clock. You have about 3 days of cover. The other 13 days are already a stockout; the email just hasn't admitted it yet.

That was our pattern across the 37 alerts. The math driving the alert was stale relative to the math driving the queue, so every alert arrived pre-baked.

What changed

I took the 37-alert analysis to the Stocura team. The fix shipped in July: alerts now fire off the same reorder point the queue itself uses. The moment a SKU crosses into "Order Now" on the 30-minute sync cycle, the email goes out, and it prints the supplier's learned lead time in the alert copy so you can see how long the fuse is. SKUs too new to have learned math use whatever manual reorder point you've set, rather than being skipped.

I'm not going to pretend any alert system is bulletproof. A single bulk order can still punch a SKU straight through its reorder point between two syncs. No cadence saves you from a customer who buys 300 units at 2 p.m. But the structural problem, alerts that trail the reorder decision by a week, is gone. The alert and the queue now disagree about nothing.

The uncomfortable half

Eleven of my 37 alerts never turned into a purchase order at all.

I'd like to report a good reason for each one. The honest accounting is that some were deliberate skips on slow movers, and the rest just fell between the Tuesday I read them and the Thursday I did the ordering run. An alert that fires at the right moment and then sits unactioned for five days has spent most of its value. The system's timing was the bigger defect, but my follow-through gave it help it didn't need.

Run this check on your own alerts this week

You need about an hour and no new software.

Pull the last 90 days of low-stock alert emails out of your inbox. For each SKU that subsequently stocked out, note two dates: alert fired, stock hit zero. Take the median gap. Compare it to your suppliers' actual lead times, from your last six POs, not from the field you filled in at onboarding.

If the median gap is shorter than your lead time, your alerts are decorative. Recalculate the thresholds from the formula above, starting with your ten fastest-moving SKUs.

Then count how many of those alerts became purchase orders, and how many days that took. Fix whichever number embarrasses you more.