Drop in your orders export. This finds the days each SKU went unusually quiet against its own weekday pattern, estimates what that likely cost, and tells you plainly which SKUs it cannot judge.
🔒 Your file never leaves this page — everything runs in your browser
Drop your orders CSV hereor click to choose a file
In Shopify: Orders → Export → All orders → CSV Works with any CSV that has a date, a SKU and a quantity — Amazon, WooCommerce, or your own.
Auto-detected from your header row. Change anything that looks wrong.
This is sample data, not your shop.
Ten invented SKUs over 90 days, generated inside this page — every figure below
belongs to a store that does not exist. It is here so you can see what the tool
does before exporting anything.
Run it on your own orders export →
Estimated revenue lost to stockouts
—
Selling stopped recently — was that deliberate?
Silent for
SKU
Last sold
Was selling
Daily pattern
If it's a stockout
These are not in the total above, and the money column is a condition, not a finding: sales data cannot tell a product that ran out from one you took down on purpose. If you delisted it, paused its ads, or it is out of season, there is nothing here to act on — the row is only telling you the silence exists. Check the ones you did not intend.
Where the money went, by SKU
SKU
Daily pattern
Sold
Avg/day
Stockout days
Lost units
Lost revenue
Status
Blue bars are daily units across the period. An orange band is a flagged outage. Short grey ticks are zero-sale days that did not clear the bar.
Next question
Now you know what it cost. What should you order?
This page looks backwards — what you already lost. Reorder Copilot looks forwards: give it your stock levels and supplier lead time and it tells you which SKUs to order this week and how many.
Order quantities sized with proper safety stock for your service level
A purchase order CSV you can send straight to your supplier
Refuses to size an order for discontinued or seasonal SKUs — the mistake that fills a warehouse with dead stock
Same rules as this page: one file, no server, works offline forever
Each of these has long silent stretches, but the shape says seasonal, discontinued, newly launched or sold in bursts — not out of stock. Putting a dollar figure on them would tempt you into buying stock you don't need, so there isn't one. Look at the pattern and judge for yourself.
SKU
Daily pattern
Sold
Silent
Looks like
Exactly how this is calculated (and where it can be wrong)
The method
Each SKU's sales are laid out day by day from its first ever sale, so a product launched in month three isn't punished for months one and two.
Every weekday gets its own baseline rate. A product that only sells on Saturdays is not out of stock Sunday to Friday — a flat average says it is, and would report several times more loss than the product has ever earned. Thin weekdays are pulled toward the SKU's own average so a single quiet Tuesday can't distort it.
Days when the entire shop sold nothing are thrown away first. Those are closures, holidays, site outages or tracking gaps. Treating them as per-SKU stockouts is how one Thanksgiving weekend becomes five figures of imaginary loss spread across the whole catalogue.
A run of zero-sale days is flagged only if the units it should have contained — adding up each day's own weekday rate — passes a bar set once for the whole report, from its total size. Checking every gap independently would manufacture findings, because a few hundred SKU-months contain thousands of chances for a quiet stretch to look like an outage.
Runs shorter than 4 days are never flagged.
A run that is still going when the file ends is never priced into the total. A product that is silent right now might be out of stock, or might be one you delisted, paused or put away for the season — the sales data is identical in every case, so any figure would be a guess dressed as a finding. Those SKUs get their own section instead, with the cost written as a condition. A product with no sales at all in the recent half of its history is treated as discontinued and gets no figure of any kind.
Lost revenue = lost units × that SKU's median unit price, and lost units can never exceed what the SKU actually sold. If the estimate wants to break that ceiling, the model doesn't fit and the SKU is moved out of the total.
What this does not know
Slow sellers are excluded, not estimated. If a SKU sells 0.3/day, a two-week gap is completely normal and the data physically cannot tell that apart from an outage. Those are reported as "not assessed" rather than given an invented number — so this total is an undercount by design.
It can't see your inventory log. It infers stockouts from the shape of your sales. A gap could equally be a paused ad campaign, a supplier delay, or a listing you unpublished.
Promotions and seasonality aren't modelled beyond the weekday pattern. A product that sells only in December will look wrong here; that's why it gets moved to the "doesn't fit" table.
Substitution isn't modelled. If a customer bought the blue one because the red one was gone, the red one's "lost" revenue was partly recovered.
Refunds and cancellations usually stay in an orders export as positive line items, so they inflate the baseline slightly. Filter them out before exporting if you can.
Mixed currencies aren't converted. If your export has more than one presentment currency, the money column here is meaningless — use the units column.
It cannot tell a stockout from a decision. Everything still silent at the end of your file is listed under "Selling stopped recently" with its cost stated as a condition, and left out of the headline. Only you know which of those you meant to do — so the total on this page counts only outages you demonstrably recovered from, and is smaller than the truth if some of that silence was unintended.
Treat this as a shortlist to go investigate, not an audited figure, and never as the sole basis for a purchase order. Open your inventory history for the top three and confirm they were actually out before you act on any of it.