Bots and Limited Release Restocks: Reading the First Ten Minutes
Restock traffic arrives as a spike that mixes loyal customers with automated buyers. How to read the first minutes and protect the drop without punishing fans.
A limited restock compresses a week of demand into minutes, and automated buyers know the schedule as precisely as your best customers do. The traffic spike that follows is a blend: genuine fans refreshing, resellers scripts polling, and inventory checkers hammering the product page long before the buy button matters.
Reading that blend correctly in the first ten minutes decides whether a response helps customers or hands the stock to the fastest scripts. This guide covers the signals and the proportionate responses.
Know the shape of a healthy restock spike
A healthy spike is broad: many distinct visitors, product page views distributed like normal shopping, add to basket attempts spread over minutes, and a checkout completion pattern that resembles a busy sale day, only faster. Human enthusiasm is messy and uneven, and the data looks it.
An unhealthy spike is narrow and regular: repeated identical requests from few sources, polling at exact intervals before the drop, basket attempts faster than a person can complete the steps, and geographic or network patterns that match no plausible fan base. Regularity is the tell. People are not regular.
Protect the queue, not just the checkout
By checkout, the contest is mostly decided, because scripts that reached checkout with stock reserved have already won the scarce resource: time. Fairness controls belong earlier: a proper queue or waiting room for the drop, per customer limits enforced from the basket onward, and product page defences against high frequency polling.
Communicate the rules before the drop: limits per customer, queue behaviour, and what happens to orders that break them. Published rules deter some abuse, reassure genuine fans that the process is policed, and make enforcement defensible when cancelled buyers complain publicly.
Make enforcement decisions on evidence you keep
Every cancelled bot order will be disputed by someone, occasionally a genuine customer caught by a blunt rule. Keep the evidence per decision: request patterns, timing, and the specific rule triggered, stored long enough to answer complaints and chargeback claims after the event.
Review false positives after each drop and tune the rules that caused them. A defence that quietly blocks a steady trickle of real fans costs more across a year than it saves in one restock, and only post drop review ever notices.
Report the drop honestly afterwards
Publish an internal drop report within days: stock sold, estimated automated share of attempts, orders cancelled and why, genuine fan success rate as far as it can be estimated, and the changes queued for next time. Label the estimates as estimates. Bot share numbers are models, not counts, and treating them as exact corrupts every later decision.
Compare drops over time rather than judging one in isolation. The trend in automated attempt share and fan success is the real scoreboard for whether defences are keeping pace with the scripts targeting your releases.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Bots Targeting Gift Card Balance Checks, Bot Traffic Around Loyalty Points Sales and Bonus Events, and Price Scraping Bots: Reading the Traffic and Protecting Your Catalogue.
Frequently asked questions
How can bots be spotted in the first minutes of a drop?
By regularity and concentration: identical repeated requests, exact interval polling, impossibly fast basket completion, and traffic concentrated in few networks. Human spikes are broad and uneven. Automated spikes are narrow and metronomic.
Where should drop defences sit, page or checkout?
Earliest is best: queueing and polling controls at the product page, limits enforced from basket onward, and checkout checks as the last layer. Checkout only defence acts after scripts have already captured the scarce stock and time.
Should per customer limits be published before a drop?
Yes. Published limits deter abuse, reassure genuine customers that the sale is policed, and make later cancellations defensible. Unpublished rules enforced after purchase generate the worst complaints, fairly.
How accurate are bot share estimates for a drop?
They are modelled estimates, not counts, and should be labelled that way in every report. Use them for trends across drops and for sizing defences, not as exact figures in public claims.