Why restock alert emails fail at the exact moment they matter

If you run a back in stock program long enough, you will eventually hit the same complaint from a customer: “I signed up for an alert and never got one.” Sometimes that is a spam filter. Often it is something more structural, and it is worth understanding the structure, because it is the same structure behind every app in this category, not a flaw unique to any one of them.

There are four places this breaks. Restock detection can miss the event entirely. The send itself can get throttled or blocked at the moment it matters most. Nobody, including the merchant, can tell what actually happened because there is no record of it. Or the alert sends perfectly and the customer still cannot buy the product, because it is not available in their market. Each one is checkable, and each one is fixable.

Failure mode 1: the webhook that did not fire

Most back in stock apps detect a restock the same way: they subscribe to Shopify’s inventory_levels/update webhook and wait for Shopify to tell them inventory changed. This is the right first step. It is not, on its own, a complete system.

Shopify’s own documentation on webhooks is direct about this: “Webhook delivery isn’t always guaranteed, and your app can miss or mishandle events for other reasons, such as handler failures or downtime.” That is not a hedge buried in fine print. It is the framing Shopify uses to introduce the topic of webhook reliability to developers building on their platform. Shopify’s stated recommendation for handling this is equally direct: “For redundancy, use reconciliation jobs to periodically fetch data from Shopify so that your app stays consistent with Shopify’s data.”

Read plainly, this means: if an app only listens for the webhook and does nothing else, it has built its core detection mechanism on a channel its own platform vendor says is not guaranteed. When a webhook delivery is missed (a timeout, a brief outage on either side, a burst of simultaneous inventory updates that overwhelms a handler), nothing else in the system knows the restock happened. No poll checks the actual inventory count. No process asks “did we miss anything in the last hour.” The restock just silently does not trigger any alert, and the first anyone hears about it is a customer asking why they were not notified, or worse, nobody asking at all, because most customers who get ignored do not follow up. They just buy from someone else.

Shopify’s guidance to run periodic reconciliation jobs alongside webhook subscriptions exists precisely because this failure mode is expected, not exotic. A reconciliation job, a scheduled check that polls actual inventory state on a fixed interval independent of whether any webhook fired, catches restocks a dropped webhook missed. It is Shopify’s own recommended backstop, not a competitive flourish.

How to check your own app: ask your provider, directly, whether restock detection runs on webhook alone or on webhook plus a scheduled reconciliation check. If the answer is unclear or defensive, that is itself informative. This is a fair, specific technical question, and a team that has actually built the backstop will answer it plainly and fast.

Failure mode 2: the send that got throttled

Say detection works and the restock event fires correctly. The next failure mode shows up on the sending side, and it is arguably more common because it is guaranteed to happen at your highest-stakes moment: the instant a popular item comes back and hundreds or thousands of subscribers all need an email within minutes of each other.

Email infrastructure treats a sudden burst of outbound mail from one sender as a signal worth watching. Google’s bulk sender guidelines and most major mailbox providers ask senders to warm up new domains and IPs gradually, ramping volume over roughly two to six weeks for typical sending and longer for very high volume, because mailbox providers use sending pattern as one input into spam filtering decisions. A domain that has been sending a slow trickle of email and then blasts several thousand messages in a single burst looks, to a receiving mail server, similar to a spam event, regardless of whether the content is legitimate. The practical result: deliverability drops right when volume spikes, which is exactly when a restock alert matters most.

This is why queued, paced sending, releasing a large batch in controlled waves rather than firing it all at once, is standard practice in bulk email generally, not a Shopify-specific trick. Google’s own sender guidelines warn against sending in bursts for exactly this reason. An app that blasts its entire subscriber queue synchronously the moment a webhook fires is optimizing for speed in a way that actively works against deliverability at the volumes that matter.

There is a second layer here specific to multi-tenant apps: a back in stock app is typically sending on behalf of many merchants from a shared sending infrastructure. If one merchant’s list has a high bounce rate or spam-complaint rate, that can affect sender reputation for the shared domain more broadly, depending on how isolated each merchant’s sending is. This is an operational detail most merchants never think about until an email stops arriving with no explanation.

How to check your own app: ask whether there is a batch size or send-pacing control you can see or set, and ask what happens on a restock that triggers, say, two thousand notifications at once. A specific answer (a described pacing mechanism, a warmed sending domain) is a good sign. A vague answer (“we handle that”) is not evidence either way, but it is a reason to ask a more specific follow-up.

Failure mode 3: nobody can tell you what happened

The first two failure modes are technical. This one is procedural, and it is the one that turns a one-off miss into a trust problem: when an email does not arrive, can the merchant, or the app’s own support team, actually find out why?

Without a send-level audit trail (a per-subscriber record of queued, sent, delivered, and clicked, tied to the specific product and variant), a missing email is undiagnosable. Support has no way to distinguish “we never triggered a send for this restock” from “we sent it and it bounced” from “we sent it and it landed in spam.” Each of those has a different fix, and none of them are visible without a log that ties a specific customer to a specific send event.

This matters more than it sounds like it should, because the fix is cheap relative to what it prevents. Logging send state is not a hard engineering problem. It gets skipped anyway, because it does not show up in a product demo and does not feel urgent until the first time a merchant asks “did my customer actually get this,” and the honest answer is “we don’t know.”

How to check your own app: ask for a specific example. Pick a subscriber and a product from a recent restock and ask your provider to show you what happened to that specific alert. If they can produce a timestamped answer, the audit trail exists. If they can only tell you the restock triggered “some” sends with no per-subscriber detail, there is a real gap in what you can diagnose the next time a customer complains.

Failure mode 4: back in stock, but not in your market

If a store sells internationally with Shopify Markets, product availability is not a single global switch. Shopify’s own documentation on catalogs explains that a catalog can have a publication attached to it, and that publication controls what a customer in a given market can actually buy: “customers that belong to the associated market or company location have access to view and purchase only the products and collections within the publication.” A product can be fully restocked, sitting at a healthy inventory count, and still be unpurchasable to a customer in a specific country, because that product was never published to that market’s catalog.

This is a separate thing from inventory. Inventory answers “do we have any.” Market publication answers “can this specific customer buy it.” A restock alert system that only watches inventory levels has no way to know the second one changed, or that it was ever missing in the first place. Shopify’s Storefront API treats this as a contextual question on purpose: as of API version 2024-04, availability fields are meant to be queried per market country using the @inContext directive, which only exists because the same product can return a different answer depending on which market is asking.

Here is where it breaks for a customer. Someone in Germany signs up for a restock alert. The item comes back in stock at the warehouse level. The app fires the alert, correctly, because inventory did increase. The customer clicks through and lands on a product page that shows the item as unavailable, because the product was never added to the publication tied to the German market’s catalog, or a market-specific change has not caught up yet. From the customer’s side this looks like a broken promise: they got the email, they clicked, and the thing still is not for sale to them. From the merchant’s side everything technically worked. The alert sent, the click tracked, the inventory number was right. Nothing flagged an error, because in the narrow sense nothing failed.

Shopify’s own tooling has a documented gap here that makes this harder to catch automatically. The same catalogs documentation notes plainly that “there are no webhooks that are associated with changes to catalogs or price lists.” So even an app that wanted to watch for a product being unpublished from a market’s catalog has no event to subscribe to, the way it does for inventory. It would have to poll catalog and publication state directly, which is a different and less common integration than the inventory webhook most back in stock apps are already built around.

Being direct about it: Kelso does not check market or catalog publication state today. Our detection is inventory-based, the same as most apps in this category. That is a real gap, not a competitive point, and a merchant selling through Shopify Markets should know to ask about it whichever app they use.

How to check your own app: if you sell in more than one market, pick a product and a market where you know the product is unpublished or restricted, and ask your provider whether their restock alert logic checks catalog and publication availability for that market before sending, or whether it only checks inventory count. If the honest answer is “just inventory,” that is not necessarily a dealbreaker, but it means you should expect this exact complaint from customers outside your main market, and you will want a manual way to catch it in the meantime.

What this adds up to

None of these failure modes are exotic edge cases. The first three are the predictable behavior of webhook-only detection, unpaced sending, and undocumented delivery: design choices that are each individually reasonable shortcuts and, combined, describe why “the email just didn’t send” keeps showing up as a recurring complaint in this category. Fixing those three is not a moonshot. It is a reconciliation poll behind the webhook, a queued sender with pacing controls, and a log table that records every send. The fourth is different in kind. It is not a shortcut anyone took, it is a mismatch between where inventory lives and where a product is published, and it only shows up once you sell into more than one market. None of it is glamorous. All of it is checkable, in a conversation with any provider, in about five minutes.

Kelso’s approach to the detection half of this is a two-path design: the inventory webhook fires for speed, and a scheduled reconciliation poll runs behind it and catches whatever the webhook drops, matching Shopify’s own recommended pattern rather than treating the webhook as sufficient on its own. If your current app can’t answer these questions and you’re weighing a switch, our free back in stock plan is $0 a month with no credit card needed, and it includes a full send audit log so you can check exactly what happened to any alert yourself.

The short version

Ask any back in stock app four questions: does detection run on webhook alone or webhook plus a reconciliation poll, is sending paced or blasted, can you trace one specific subscriber’s alert from queue to delivery, and if you sell in more than one market, does it check that the product is actually purchasable in the customer’s market before it sends. The answers tell you more about whether alerts will actually arrive, and actually help, than any feature list or star rating will.

Better than asking is proving it. You can run the first three checks on your own store in about ten minutes with a spare email and a cheap product: here is how to test your back in stock alerts before you trust them.