A restock alert sounds like a tiny programming exercise.
- Check whether a product is in stock.
- Notice when the answer changes.
- Send a notification.
That version works until real shoppers depend on it.
Retail inventory is messy. A product page can say one thing while checkout says another. Availability can vary by location. A popular item may disappear between the alert and the tap. Sometimes a retailer changes a page and the signal simply vanishes.
We ran into all of this while building Restockd, a free app for Pokemon restocks and other hard-to-find collectibles. The difficult part was not checking pages. It was deciding when an observation was trustworthy enough to interrupt someone.
This article covers the reliability lessons without getting into our retailer-specific methods or infrastructure.
"In stock" is not a clean fact
Most alerting systems begin with a boolean:
in_stock = true or false
The real world gives you something closer to a collection of clues.
A page may show an Add to Cart button for an item that cannot be purchased. Search results may update before the product page. A store can expose regional availability that does not match what another shopper sees. Cached content can make old inventory look current.
Treating every positive observation as equally trustworthy produces fast alerts, but it also produces bad alerts. Treating every disagreement as a reason to wait produces cleaner alerts, but shoppers arrive after the item has sold out.
The useful question is not "Is this in stock?" It is "What evidence do we have, how fresh is it, and what is the cost of being wrong?"
You do not need a complicated scoring model to improve this. Start by keeping the raw observation separate from the decision to notify. That separation makes it possible to change your alerting rules without pretending the source data was more certain than it really was.
Speed and confidence pull in opposite directions
For ordinary monitoring, another confirmation check may cost very little. For a limited Pokemon release, a short delay can be the difference between checking out and missing the drop.
There is no universal delay that solves this. The right choice depends on the product, the source, and what users expect from the alert.
What helped us was measuring the two failures separately:
- A false positive sends someone to an item they cannot buy.
- A late alert is accurate but arrives after it is useful.
Calling both of them "bad data" hides the tradeoff. Once you measure them separately, you can decide which mistake is more costly in each situation.
This also changes how you test. A monitor that correctly reads a page is not necessarily a good alerting system. The product has to be judged at the moment the notification reaches a person.
Duplicate alerts are a product failure
Inventory often flaps. An item appears, disappears, and returns. Different locations may report changes at slightly different times. A retry can repeat an event that was already processed.
Every one of those observations may be technically valid. Sending a notification for each one still feels broken.
Users do not care how many internal events occurred. They care whether there is a new buying opportunity. That means an alert needs its own lifecycle, separate from the stream of inventory observations.
The exact rules will differ by product, but the questions are broadly useful:
- Has this person already been told about this availability window?
- Did anything meaningful change since the previous alert?
- Is a repeated alert useful, or are we just exposing internal noise?
Retries should be safe as well. If processing the same event twice sends two notifications, a temporary failure can turn into spam. Idempotency is not merely backend housekeeping here. It protects user trust.
Freshness should be visible
An inventory label without a timestamp makes a stronger promise than most systems can keep.
"In stock" could mean the system saw availability five seconds ago or twenty minutes ago. Those are different claims, especially for products that sell quickly.
Showing when information was last observed gives users context. It also forces the team building the product to confront stale data. A pipeline can look healthy because it is returning successful responses while silently serving old information.
Freshness belongs in monitoring too. Track the age of the last useful observation, not only whether the latest request succeeded.
A notification channel changes the message
A push notification, a community post, and a social update may describe the same restock, but people encounter them differently.
A phone notification must make sense on a lock screen. A community message can include more context. A public post may reach people who have never heard of the product being tracked.
Copying one payload into every channel usually leads to clipped titles, missing context, or links that are hard to act on. Keep the underlying event consistent, then format it for the place where someone will read it.
Delivery guarantees differ too. Some channels retry. Some rate-limit bursts. Some accept a message and fail later. "The request returned 200" is not the same as "the user received a useful alert."
Silence is part of the product
The instinct when building alerts is to maximize coverage. More products, more events, more notifications.
People experience that as noise.
A useful alert system needs ways to stay quiet. Users should be able to choose what they care about. The system should suppress repeated information. Operational messages should not leak into customer channels. When confidence is poor, showing uncertain availability in the app may be better than sending an interruption.
Notification volume is an easy metric to celebrate and a bad measure of usefulness. Watch what people do after an alert. Also watch whether they mute notifications or leave.
Design for failures you cannot reproduce later
Third-party pages change. Regional responses differ. Short-lived inventory disappears before an engineer can inspect it. The hardest failures often look normal by the time someone investigates.
Keep enough evidence to explain why the system made a decision. That does not mean storing everything forever. It means recording the pieces that answer practical questions:
- What did we observe?
- When did we observe it?
- Why did that observation become an alert?
- Which delivery attempts succeeded or failed?
This is more useful than a log line that says "notification sent." When someone reports a bad alert, the goal is to reconstruct the decision, not merely prove that code ran.
The part worth getting right
The code that checks availability is only one part of a restock product. The lasting work is turning unreliable outside signals into notifications people trust.
For us, that meant separating observations from alert decisions, treating duplicates as a user-facing bug, making freshness visible, and evaluating success at delivery rather than ingestion.
Those ideas apply well beyond retail. Any system that watches an outside source and interrupts a person has the same responsibility: be fast enough to matter, quiet enough to keep enabled, and honest about what it knows.
