Help centre

Getting started

1. Install

Install from the Shopify App Store. There is no account to create and no API key to paste. The app authenticates through Shopify.

2. Turn on the app embed

This is the step everyone misses, and nothing works without it.

Online Store → Themes → Customise → App embeds → StockWait alerts → toggle on → Save

The embed is what puts the "Notify me when available" button on your product pages. It is stored in your theme, so turning it on in one theme does not turn it on in another. If you publish a different theme later, switch it on there too.

3. Check it worked

Open any product that is sold out and look for the button under Add to cart. If the product is in stock, the button is correctly hidden, because there is nothing to wait for.

No button on a sold-out product? Go to The button does not appear.

4. Send yourself a test alert

StockWait → Email → Send test, and enter the address you want it sent to. It uses the same renderer and the same copy as a real alert, so what you see is what your shoppers get.

Theme placement

This is the most common thing merchants ask about, so it is the longest section here.

How placement works

The button is inserted after your theme's Add to cart button. StockWait looks for that button using an ordered list of the markup patterns Shopify themes actually use, most specific first, and stops at the first match. It reads your product's variants from Shopify's own product data rather than scraping your page, which is why it works on themes it has never seen.

If it cannot find anywhere sensible to put the button, it renders nothing at all. A missing button is a support ticket; a button jammed into a broken layout is a one-star review.

Verified themes

Checked 2026-08-25 against each theme's real product markup. Where the button lands differs by group, which matters when you are deciding whether "it's in the wrong place":

Group A: the button sits inside the buy-button block, directly under Add to cart

Dawn · Refresh · Craft · Sense · Spotlight · Studio · Taste · Origin · Publisher · Ride · Crave · Colorblock

Group B: the button sits directly beneath the Add to cart button

Horizon (Shopify's current default theme) · Impulse · Symmetry · Turbo · Debut

Group C: the button sits beneath the product form's submit button

Prestige · Warehouse

Not yet verified: Trade. It should behave like Group A, but we have not confirmed it on a real store, and we would rather say so than guess.

Your theme is not listed? That is usually fine. The matching is based on markup patterns, not a theme allowlist, and most themes use one of the patterns above. Install, enable the embed, and look at a sold-out product. If the button is there, you are done.

The button is in the wrong place

Use a custom selector.

StockWait → Settings → Button placement → Custom CSS selector

Enter a CSS selector for the element you want the button to appear after. For example:

form[action*="/cart/add"] .product-form__buttons

To find the right selector: right-click your Add to cart button → Inspect → find the element that wraps it → use its class. If the selector matches nothing, the button does not appear, so check a sold-out product after saving.

The button does not appear

Work through these in order. They are ordered by how often each turns out to be the cause.

1. 1. The app embed is off. By far the most common. See

Turn on the app embed. Remember it is per theme.

1. 2. The product is in stock. The button only shows on sold-out variants. Check the specific

variant, not just the product. A product can be in stock in one size and sold out in another.

1. 3. You enabled it on a different theme than the one that is published.
2. 4. Your theme's markup does not match. Set a custom selector, above.
3. 5. You are looking at a cached page. Hard-refresh, or open the product in a private window.

Still nothing? Contact us from StockWait → Support. Your shop details and recent restock activity are attached automatically, so you do not need to tell us your store URL.

Placing the button somewhere specific

If you want full control, use the app block instead of automatic placement:

Customise → select your product template → Add block → Back-in-stock button, then drag it exactly where you want it, and set Settings → Button placement → Only where I place the app block.

Settings explained

Minimum units to alert on

Default: 1.

Restocking three units of a product 4,000 people are waiting for means 3,997 people click through to a sold-out page. That does not just waste the alert. It teaches those shoppers that your alerts are not worth opening, which costs you the next restock too.

Raise this if you frequently restock in small quantities. If you are unsure, leave it at 1 and use "Alert only the first N" instead, which is the gentler version of the same idea.

Alert only the first N shoppers

Default: off (everyone is alerted).

Alerts the oldest subscribers first, up to your limit. This is the honest answer to a small restock: the people who waited longest get the chance, and nobody else is sent to a sold-out page.

Cooldown

Default: 24 hours.

A variant that has just alerted will not alert again within this window, whatever its inventory does. This exists because inventory numbers move for reasons that are not restocks (cancellations, returns, syncing errors, a bulk import), and each of those can otherwise fire a fresh round of emails to the same people.

Lowering this is usually the wrong fix. If you are missing genuine restocks, the cause is almost always the minimum-units threshold, not the cooldown.

Daily alert cap

Default: 50,000.

A backstop against a bulk inventory import turning into a send storm. You will not hit it in normal operation, and it is deliberately high enough not to interfere with a real restock.

Excluded products and collections

Products you never want alerts for: samples, retired lines, made-to-order items.

Sending window (quiet hours)

Default: off, and we recommend leaving it off.

Merchants ask for this, and it is a trap. A restock alert delayed eight hours is worthless because the stock is gone, usually to the shoppers who got theirs immediately. We support it because you may have a reason, but the honest advice is that quiet hours cost you sales.

The window is evaluated in the shopper's local time, not yours.

From name, reply-to, and custom sending domain

Alerts are sent from our shared sending domain by default, which is monitored for deliverability.

On paid plans you can send from your own domain, which means the alert arrives from an address your shoppers recognise. This requires DNS records and is verified before it is used. Until verification passes, sending falls back to the shared domain rather than failing.

Understanding the numbers

Recovered revenue

The value of order lines bought by shoppers who clicked one of our alerts.

It is deliberately conservative, and it undercounts. Three rules make it that way:

• Line value, not order value. If someone clicks an alert for a $25 item and also buys a

$340 jacket, we count $25. Counting the whole basket would inflate the figure, and the first time you checked it against your Shopify analytics you would stop trusting everything else in the app.

• **The shopper and the product must match**, within a time window (72 hours by default).

Someone on three waitlists who buys something unrelated is not counted.

• Guest checkouts under a different email never match. We would rather miss a sale than

claim one.

So treat it as a floor, not a measurement.

Waiting demand

How much revenue is sitting in your waitlists right now: people waiting × the price at the time they signed up.

Price at signup, not today's price. If you discount an item, the demand that accrued at full price is not silently rewritten; the history stays honest.

Waiting demand is not a forecast. It is what people have already told you they want. Not everyone waiting will buy.

Why estimates show a range

Restock recommendations show a range rather than one number because a point estimate implies a precision we do not have. The range narrows as we accumulate your store's own conversion history; until then it is based on a platform-wide starting assumption, and we say "not enough data yet" rather than dressing up a guess.

Troubleshooting

My customers did not get an email

Open StockWait → Support. The last five restocks are listed with the reason for each. The reasons mean:

No restocks listed at all? Then we never saw one. In order of likelihood: the app embed is off, so nobody ever joined a waitlist; or the restock happened before you installed.

Alerts are paused: what that means

If your plan's alert allowance is used up, sending pauses but capture keeps running. Shoppers can still join waitlists and you keep collecting demand data; you just are not emailing them yet. Upgrading sends the queue.

We also pause sending automatically if a store's spam-complaint rate crosses a safety threshold. That protects your deliverability and everyone else's on the shared domain. If this happens we contact you; the usual cause is an imported list rather than organic signups.

Someone says they are getting emails they did not ask for

Every signup records when consent was given, from where, and the wording shown at the time. Send us the address from StockWait → Support and we can tell you exactly what they agreed to and when.

Every alert carries one-click unsubscribe, and unsubscribes are honoured immediately and permanently. An address that unsubscribes stays suppressed even if it is added again later.

Does StockWait slow down my storefront?

Measured on a live storefront: 9.4 KB total, both files non-blocking, about 1% of a typical product page's weight. The script is served from Shopify's own CDN, not from us, so it is never in the critical path of your page loading.

Does StockWait use cookies or track my shoppers?

No. The widget sets no cookies, uses no local storage, loads no analytics, and does not fingerprint. It makes exactly two requests: one to read your settings, one to submit a signup.

Full detail is in the privacy policy.