Troubleshooting

Most reports come down to one of the first three sections. Work down the list — they're ordered by how often they turn out to be the cause.

Nothing happens on the storefront

No waiting room, no banner, no redirect.

1. Is the app embed on?

The most common cause by a distance. Installing the app doesn't put anything on your storefront by itself.

Online Store → Themes → Customize → App embeds → WaitRoom → on → Save.

2. Ask the page what it decided

Add ?wr_debug=1 to any storefront URL:

https://your-store.com/?wr_debug=1

Open the browser console. You'll get something like:

[waitroom] page {tpl: "index", path: "/", product: false, redirect: true}
[waitroom] triggers [{d: "cmsf8tf…", t: "s", v: null}]
[waitroom] matched {d: "cmsf8tf…", t: "s", v: null}
[waitroom] redirecting https://…/apps/waitroom/queue?drop_id=…

Each outcome means something different:

The debug flag is off without the parameter, so shoppers never see it.

3. Is the drop actually live?

A drop only intercepts once it's ACTIVE, or once its waiting room has opened. A drop scheduled for next week doesn't redirect anyone today — deliberately.

Check the drop page. If it says held back, another live drop shares a product with it: two live drops can't gate the same product, because the checkout gate names one drop at a time. End the other one and this opens by itself within seconds.

A shopper says they see nothing, but others do

Almost always deliberate. The waiting room remembers three things per drop:

• They hold a live pass. They've already been released — there's nothing to offer them.
• They're finished with this drop. They hit their limit, or weren't eligible. The queue would only refuse them again.
• They chose to leave. The forced redirect stops, but the banner still offers a way back in.

Clearing site data for your store resets all three.

The drop time is an hour out

Fixed in August 2026. Times are now resolved in your timezone rather than the server's.

Drops created before that fix still hold the old value. Open the drop, check the start time reads what you meant, and re-save it if not.

Someone bought more than the limit

Work through these in order:

1. Were they signed in? Guest purchases have no account to count against. Turn on require login for the drop to close this.
2. Is the limit per product or per drop? Per product means the cap applies to each product separately; per drop totals them.
3. Did the drop actually gate the product? The drop page lists what it covers. A product added to a collection after the drop was built isn't included until you press Re-sync from collection.

A scheduled restock didn't apply

Open Restocks and look at the plan's status.

• PARTIAL — some lines landed and some didn't. The failed ones show why. Retry what failed re-applies only those, never the ones that worked.
• FAILED — nothing landed. Usually a variant that isn't stocked at that location, or isn't tracking inventory at all.
• Still PENDING after its time — the app may be missing the inventory permissions. Reinstall it; write_inventory and read_locations were added later and existing installs keep the older grant.

If the locations dropdown is empty when building a plan, that's the same cause.

Emails aren't sending

Customer notifications and merchant alerts both need mail configured on the install. If it isn't, the app says so rather than pretending — the support form inside the app shows exactly which settings are missing.

Note that queue notifications are a paid-plan feature. The queue itself works without them.

Still stuck

Use the support form inside the app rather than the public one — it sends your plan, your recent drops and whether the checkout rule is switched on, so the first reply can be an answer rather than a question.

If a drop is live right now, say so in the first line.