The Drop-Day Proxy Runbook: What To Do, and When

Most proxy advice for releases is a shopping list. This is a schedule. Nearly every failure on drop day traces back to something that should have been done hours earlier, and the fix is almost never buying more addresses at the last minute.

The night before

Everything that can be verified in advance should be verified in advance, because at T-2 minutes you will not have time to discover that a region is misconfigured.

Check three things. That every IP you intend to use actually answers — a pool you bought last month is not a pool that works tonight. That the geography matches the release: a regional drop resolves stock from the visitor's location, and an address in the wrong country is not a slow entry, it is no entry. And that each browser profile is bound to one address and has been opened at least once, so the first request of the night is not also the first request that profile has ever made.

Write the mapping of profile to address down somewhere outside the tools. When something breaks mid-drop, the difference between a thirty-second fix and a lost release is knowing which profile is on which IP without having to look it up in three places.

Split monitor and checkout pools

This is the single change that improves results most, and it is free.

Monitoring hammers a product endpoint every few seconds for an hour. That traffic pattern is conspicuous by design and it degrades whatever address it runs on. Checkout needs an address with no history of hammering anything.

Run them on separate pools. If the same IP polls a stock endpoint four hundred times and then attempts a purchase, the purchase carries all the suspicion the monitoring earned. Keep monitors on cheap, disposable addresses — they only need to see a number change. Keep checkout on clean residential or static ISP addresses that have done nothing all day.

T-60: warm-up

An address whose entire history is one checkout attempt looks exactly like what it is. An hour before the release, put light, ordinary traffic through each checkout profile: load the homepage, browse a category, sit on a product page, leave. Not a script hitting the same URL on a timer — actual varied navigation with pauses in it.

This is also a free health check. Any profile that throws a challenge during warm-up was going to fail at checkout, and you now have an hour to swap it instead of discovering it during the release.

T-10: freeze changes

Stop touching the configuration. Every drop-day post-mortem contains at least one failure caused by a last-minute edit — a mistyped port, a region changed on a hunch, an extra task added to a profile that was already fine.

If a profile is broken at T-10, remove it. Do not repair it. A working setup with six profiles beats a broken one with ten, and the repair almost never lands in time.

During the drop

Once it starts, your options are narrow, so it helps to know what they are.

If a profile gets challenged, retire that address for the night. Retrying the same IP through a challenge is the most common way people turn one failure into a pattern. Move to a held-back spare — which is why you keep spares.

Do not rotate mid-checkout. If the address changes between the cart and the payment step, the session breaks in a way that reads as fraud, and you lose an entry that was otherwise going to land. Sticky means sticky until the order confirms.

Resist adding tasks. Load that seemed fine at T-30 behaves differently under release traffic, and each extra task competes with the ones already running.

The part everyone skips: the post-mortem

Within a day, while it is still fresh, write down four numbers: how many profiles attempted, how many reached checkout, how many were challenged, and how many completed. Note which regions and which address type each sat on.

After three or four drops this stops being anecdote and becomes data. You will usually find the failures concentrate somewhere specific — one region, one address type, one pool bought at one time — and that is a fixable problem rather than bad luck. Operators who keep this record buy far fewer proxies than operators who do not, because they stop replacing things that were working.

FAQ

How many spare addresses should I hold back?

Enough to replace roughly a quarter of your checkout profiles without thinking about it. Spares you never use are cheap; spares you needed and did not have cost the release.

Does warm-up work if I do it in ten minutes rather than an hour?

Partially. The point is a history that is not one burst, so spread over an hour beats compressed into ten minutes — but ten minutes beats nothing.

Should monitors and checkout be in the same city?

The same country matters; the same city rarely does. What matters far more is that they are not the same addresses.

Is one IP per profile really necessary?

For checkout, yes. Two profiles sharing an address are one linked pair, and a flag on either lands on both.