The expensive part of an inventory sync failure is not the failure. It is the time before anyone noticed. A store that ran three days without syncing and a store that caught it in three hours face completely different clean-ups: the first re-counts the warehouse, the second fixes the sheet and runs once.
Unfortunately, an inventory sync will not tell you it has broken. This article looks at what to watch in order to spot trouble quickly, and how to do it without standing up any monitoring infrastructure. All it takes is a few small devices and being ready to act when one of them fires.
Inventory sync stops quietly
Before talking about monitoring, it is worth being precise about how an inventory sync actually breaks. Once the failure modes are clear, where to point your attention follows naturally.
A success log is not a health check
When the sync log says success, all that means is the run finished without raising an error. A run with zero SKUs in scope succeeds. A run whose sheet range slipped and read only empty rows succeeds. The absence of errors and the presence of correct work are two different things.
That distinction is the starting point for any monitoring design. What you want to know is not whether an error occurred but whether the intended thing happened. Watch only for errors and you miss the quietest, longest-running class of failure entirely. What to keep in the log is covered in sync logs as an audit trail.
Three ways it stops
Sync failures fall into roughly three groups. First, the sync stops running at all: a schedule was removed, credentials expired, sheet sharing settings changed. This is the most legible kind of stoppage — once you notice, the cause is usually right there.
Second, it runs but changes nothing, because columns or rows shifted or the target range came back empty. Third, it updates but writes the wrong things, typically because it is reading one column across and putting one SKU's number onto another. That third one is the hardest to spot and does the most damage.
In practice the second and third are the ones you actually meet. The first — not running at all — is a credentials or schedule problem, and those usually leave a record somewhere. The other two begin with somebody casually doing something in the sheet: inserting a column, closing it with a filter still applied, re-sorting rows. None of it malicious.
Which means monitoring should be designed around human edits rather than system faults. The great virtue of a sheet is that anyone can open and fix it, and this risk is the flip side of that virtue. Narrowing who has access helps, but restrict it too far and the process itself stops working.
Time to detection is the cost
The cost of a sync outage scales almost linearly with elapsed time. At the instant it stops, sheet and Shopify agree exactly. Divergence only accumulates from subsequent sales and receipts. Stop for a day and you have a day of drift; stop for a week and you have a week of it.
That property makes the investment decision unusually clear. You do not need perfect monitoring. Turning a week of not noticing into a day of not noticing prevents most of the damage. The target is not precision — it is shortening time to detection.
What is actually worth watching
The list is shorter than you might expect. Did it run, did it change anything, does it still match. Those three catch the three failure modes above, one each. Let us take them in turn.
Did it run
The most basic check is whether the sync executed on schedule. If you have a scheduled sync, glancing at the run record each morning catches the first failure mode outright. A run timestamp still showing yesterday means something has happened.
This does not need automating — one look at a screen when the day starts is enough. Human eyes are arguably better here, because they notice things like it was slow last week too. Monitoring makes people think of automation, but a habit of looking at the same thing at the same time each day is monitoring in its own right.
Expired credentials deserve particular attention. The access your sync relies on can lapse through a password change, a permissions review, or somebody leaving. And this kind of stoppage is especially easy to miss, because nothing is broken on either the Shopify or the sheet side. Only the run timestamp quietly stops moving.
In any week when account changes happen internally, make a point of checking the next day's run record. Offboarding procedures and inventory sync normally live in completely separate conversations. Simply knowing the two are connected prevents a whole category of incident.
Did it change anything
Next, how many SKUs that run actually updated. In a store where around thirty items update daily, a day with zero updates is a signal. Equally, a day where eight hundred updated in a store that normally sees thirty is worth a look.
Count anomalies are the signal that structural sheet changes produce. Somebody inserted a column, saved with a filter applied, re-sorted the rows. These things happen innocently and the person responsible has no idea. A single one-dimensional number stands in for all of them.
Does it still match
Catching the third mode — updating with wrong content — means comparing actual figures. You do not need to reconcile the whole catalogue daily, though; checking a handful of fast movers periodically works well, because that kind of failure usually affects everything uniformly.
When comparing, put the sheet quantity next to Shopify's on hand. Comparing against available makes every check look wrong, because available is smaller by whatever is committed. Choosing the right comparison turns this from a puzzling task that always shows a gap into one where only genuine anomalies stand out. Four numbers that tell you if your sync works defines how to measure accuracy.
- Did it run — the run timestamp; catches removed schedules and expired credentials
- Did it change anything — the update count; catches structural changes in the sheet
- Does it still match — spot-check key SKUs; catches mapping errors
- Compare against on hand, not available, or every check looks like a discrepancy
Building the alerts
With the watch list settled, next comes notification. You can get a long way without any dedicated monitoring tool, using Shopify's own features plus a couple of spreadsheet tricks.
Using Shopify Flow to catch stock movement
Shopify Flow, Shopify's own automation app, lets you build workflows that send notifications when inventory changes. There is a product variant inventory quantity changed trigger, and the source of the change — an order, a manual edit, or an app — is available as a condition.
There are low-stock notification templates too, so getting an email or Slack message when a variant drops below a threshold takes a few clicks. The Help Center also documents how to write the condition so it fires only when stock crosses the threshold, rather than every time it moves below it.
Put a canary in the sheet
There is a delightfully simple way to confirm the sync is alive: keep one row in the sheet purely for monitoring. Create a test SKU you never actually sell and change its quantity every day. If that number has changed on the Shopify side, your sync is definitively alive.
What makes this trick good is that it detects all three failure modes at once. If nothing ran, the number does not move. If the range shifted, the row is not read. A number that changed proves the whole path from sheet to Shopify is intact. The check itself takes ten seconds.
When creating the monitoring SKU, make sure it stays unpublished — keep the product as a draft or archived so it never reaches the storefront. Inventory tracking does need to be enabled for it, so confirm that combination of settings once before relying on it.
How you choose the quantity matters too. Use the last two digits of the date, or simply alternate between one and two. With a rule in place the expected value is obvious at a glance: knowing today should read 21 lets you judge the moment you look at Shopify. A pattern makes the check faster than a random number ever will.
An alert that fires constantly is the same as no alert
The trap everyone falls into is notifying too much. Set an alert on every stock movement and dozens land per day; within two weeks they are auto-filed into a folder nobody opens. That is more dangerous than having no monitoring, because you believe you have some.
The remedy is to restrict notifications to moments that require a response. Stock going down is normal and needs no message. Crossing a threshold for the first time, a sync that did not run at its scheduled time, an update count of zero — fire only when a human genuinely has to do something.
What happens after it fires
The part most often skipped in monitoring design is the response. A notification that arrives without anyone knowing what to do changes nothing. So let us settle what happens once something fires.
The first five minutes
- 01Open the sync run record and find when it last succeeded
- 02Open the sheet and check that column positions and the target range are unchanged
- 03Check whether the monitoring SKU's number has reached Shopify
- 04Pick three key SKUs and compare the sheet quantity against Shopify's on hand
- 05If the cause is still unclear, duplicate the sheet as it stands before investigating further
That last step is unglamorous and important. Editing the sheet mid-investigation destroys the evidence of what it looked like. Google Sheets keeps version history so recovery is possible, but taking a copy is both surer and faster. The more urgent things feel, the more that small step pays. The recovery that follows is recovering from a bad inventory sync.
Write the procedure on one page
Put the steps above on a sheet tab or an internal doc, one page long. Fitting on a single screen is enough. Long runbooks do not get read, and nobody has the patience for prose in the middle of an incident. Five to ten lines is a realistic ceiling.
Do not stop at the steps. Note who to contact, which screens to open, who is able to re-authorise access. With all of that on one page, somebody else can act when the usual owner is away. As a defence against knowledge living in one person's head, that page earns its keep.
Review the alerts themselves monthly
Alerts are not finished once built. Once a month, look back at everything that fired and ask whether each one actually needed a response. Anything that never did is a candidate for a tighter condition or removal. Conversely, if a problem was found without any alert, that is where a new check belongs.
Keep that review going and the volume falls while the weight of each message rises. What you want is something that rarely fires and always gets read. Approach it as a few months of gradual tuning rather than trying to get it perfect on day one.
Monitoring an inventory sync needs no elaborate machinery. Watch three things, fire only when somebody has to act, and keep the response on one page. That alone shortens time to detection dramatically.
And remember that the value of monitoring cannot be measured in incidents prevented. A long run of uneventful days is not evidence that it was unnecessary — it is evidence that it is working. Against a system that fails quietly, quietly watching is the surest preparation there is.