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 three places this breaks. Restock detection can miss the event entirely. The send itself can get throttled or blocked at the moment it matters most. Or nobody, including the merchant, can tell what actually happened because there is no record of it. 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. Sending domains and IPs need a warm-up period, ramping volume gradually 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 transactional email generally, not a Shopify-specific trick. 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.

What this adds up to

None of these three failure modes are exotic edge cases. They are the predictable behavior of webhook-only detection, unpaced sending, and undocumented delivery: three 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 all 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. 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.

The short version

Ask any back in stock app three questions: does detection run on webhook alone or webhook plus a reconciliation poll, is sending paced or blasted, and can you trace one specific subscriber’s alert from queue to delivery. The answers tell you more about whether alerts will actually arrive than any feature list or star rating will.