Two exit IPs inside one alert window breaks the state
The event monitor that generates support tickets is usually not completely broken. It keeps refreshing, the alert system accepts whatever the parser hands it, and nobody notices until fourteen "available" alerts fire in two minutes while the page still shows no usable inventory.
The failure mode is usually an exit IP change mid-session. A worker entered a queue on one exit, refreshed from a different exit, and carried the old browser state forward. Cookies and queue token said one thing; the network route said another. The fix was to pin each worker to one static line and replay the event page slowly until the map state and alert state matched.
Static ISP is the right tool here because the exit stays fixed indefinitely. Not for speed, and not because rotating residential is bad — for broad discovery, rotation is fine. For a worker babysitting the same public event page through a long window, the network side should be boring while cookies, queue tokens, and browser storage do their work.
One worker, one static line, one browser profile
A venue or event group stays with its browser profile and its proxy line for the full monitoring window. If the workflow includes an account that is authorized for that run, that account stays with the same worker. Adding more exits would not have fixed the false-alert problem above; it would have made the ticket harder to explain.
On Proxynade, the Static ISP line connects through proxynade.net:2555 with username and password auth. HTTP, HTTPS, and SOCKS5 all use the same port. Use SOCKS5 if the client requires it — the protocol uses username/password sub-negotiation to pass credentials; otherwise the protocol label matters less than keeping the exit fixed. Static ISP is billed per IP with unlimited bandwidth, so a worker refreshing the same page all day does not accumulate a per-GB charge with each poll.
Alert count and byte count tell different stories
The app's alert counter tracks state changes or sent notifications, not connection attempts. Refreshes, retries, queue placeholders, blank HTML, and challenge pages all consumed the connection even if none produced a useful signal. If the monitor reports "nothing changed" but the dashboard logs show a pile of low-byte responses, the polling cadence is the first thing to audit — not the proxy count.
The Proxynade dashboard network log shows host, outcome, latency, and byte totals per request. A normal page load has a recognizable byte range; a challenge page or sold-out stub is much smaller. Comparing those two columns is faster than reading response bodies in the app.
Jitter before adding more workers
Sold-out pages can usually poll on a slow cadence without missing real inventory changes. Known release windows can run tighter, but workers should not refresh in lockstep. A synchronized burst from multiple workers looks like a scraper and can trigger rate limiting that slows the entire monitoring run.
When a worker starts returning empty bodies or unexpected status codes, pause it and compare the browser profile and queue state against the exit IP, status, latency, and response size in the dashboard logs before scaling the setup. More workers will not fix a session state mismatch.
Monitoring workers should stay separate from any action-taking logic. That separation is also an audit requirement: if an alert fires and someone asks what the worker did, the answer should be limited to reads of public pages. If the workflow has explicit authorization to do more, document that before the run and keep it consistent with the AUP at /acceptable-use.