Four things sit between a shop restocking and your phone buzzing. Only one of them is the tool you picked, and the other three are fixable.
Restock alerts arrive too late for four reasons, and only one of them is the tool you picked. The check ran too far apart. The page you were shown came out of a cache. Add an email queue and a sleeping phone, and those delays stack on top of each other.
Slow restock alerts are rarely one big failure. An alert is a chain, and every link costs time. Something has to notice the change, work out that it matters, hand it to a delivery channel, and get it in front of you. The shop is only involved in the first step of that. Below are the four places the time actually goes, roughly in the order they cost the most.
Half the interval, on average. A monitor checking every 60 seconds sees a change 30 seconds after it happened on a typical run, and 60 seconds after it on a bad one. Stretch the gap to 15 minutes and the average becomes seven and a half minutes, which is longer than a lot of drops last.
StockWatch checks every 60 seconds on the free plan, every 15 seconds on Standard and every 5 seconds on Power User. Which one you need is a question about the item rather than about the plan. A saucepan that restocks weekly is fine on 60 seconds. A Pokemon Center exclusive is not, because those usually go on the day the preorder opens.
There is a ceiling on this, and it is the shop rather than us. Hammering a whole catalogue every 5 seconds gets an IP blocked, which turns a fast monitor into no monitor at all. Our note on intervals has the ranges that hold up in practice.
Yes, and it can fool you again after the alert lands. Shop pages normally sit behind a CDN, which hands out a stored copy instead of asking the shop every time. Cloudflare's documented default Browser Cache TTL is 4 hours, and it applies that default when the shop's own server sends no caching headers of its own.
So the page sitting in your browser can be hours old. That is why an item sometimes reads as sold out the second you tap an alert, then reads as buyable after a hard refresh. Nothing changed at the shop in those two seconds. You were looking at your own copy first.
The way around it is to ask for the data the shop's own basket reads, rather than scraping the marketing page a CDN is happy to cache. Monitoring a website for changes covers where those two things part company.
Because an index is a copy, and copies go stale on their own schedule. Google's Merchant Center marks a product as needing an update 30 days after its last change, which shows how loose the freshness expectation is even for a feed a shop maintains on purpose. Ordinary web results have no feed behind them at all.
An item shown as available in a search result, a shopping tab or a price comparison page was available at some point. It tells you nothing about the last five minutes.
Because email was built to be reliable rather than quick. If the first delivery attempt fails, RFC 5321 tells the sender to wait before trying again, and it puts a floor on the wait.
The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes.
One temporary hiccup at your mail provider, greylisting included, and the alert lands half an hour behind the copy that went to Discord. Nothing has broken. That is the protocol doing exactly what it says on the tin. Treat email as the record and something instant as the alert.
Because the phone decided it could wait. Android batches deliveries while a device is idle, and Firebase is blunt about what that does to an ordinary message.
Normal priority messages are delivered immediately when the device is not sleeping. When the device is in Doze mode, delivery may be delayed to conserve battery until the device exits doze.
High priority messages are allowed to wake a sleeping device, which is why a stock alert should be sent as one. At your end, two settings are worth checking. Exempt whatever delivers your alerts from battery optimisation, and make sure Do Not Disturb is not quietly swallowing it.
Three places, and naming them is fairer than pretending otherwise.
For the shortest chain we can offer: one product per monitor, the fastest interval your plan allows, and the alert going to Discord or push rather than to an inbox. How to get restock alerts in the UK compares the channels side by side.
Four delays, and they stack. The gap between checks, a cached page served instead of a live one, an email queue that can hold a message for 30 minutes after one failed attempt, and a phone in Doze mode sitting on an ordinary push message until it wakes.
Only up to the point where the shop starts blocking you. Below about 5 seconds you are making noise rather than gaining time, and a blocked IP is slower than a steady 60 second check.
Usually a cache rather than the stock. Cloudflare applies a 4 hour default browser cache when a shop sends no headers of its own, so a hard refresh is worth trying before you believe the page.
Discord, Telegram and browser push all hand the message straight to a live service. Email is the one of the four with a retry queue in front of it, and RFC 5321 puts that wait at 30 minutes or more after a failed attempt.
Both get a share. The shop controls how cached its pages are and how quickly its own stock system updates. The tool controls how often it looks and how it delivers. What you control is the interval, the channel and your phone's battery settings.
Watch a page and time it yourself Five pages free, checked every 60 seconds, no card needed.