Static ISP is not the first answer
If a 20-minute sticky window covers the whole workflow, sticky residential is sufficient. Static ISP is for the job that needs the same exit tomorrow: a vendor portal your team is authorized to use, a QA run that must come from one country, a dashboard allowlisted by network address. When there is an API, export, or partner feed available, use that instead. Cleaner audit trail, fewer moving parts, fewer browser-state bugs.
A fixed IP does not fix authorization. If the target does not permit the workflow, a static line gives you a more consistent way to get blocked.
Two failures look identical in a thin log
The IP changed, or the browser state vanished. The second cause is more common than most teams expect. I have watched teams rotate IPs for an hour while the CI runner had simply deleted the browser profile between jobs.
Browser state and proxy line must travel together. Cookies, local storage, account ID, browser profile path, and last good step should be stored in the same place. The same static IP reaching the login page from a familiar address does not restore a lost session — it just starts a new one from a known location. Playwright's proxy configuration docs show how to bind a proxy line to a browser context so the pairing is explicit in code, not assumed.
Name lines by workflow, not by person
Generate the static ISP line from the Proxynade dashboard for the specific workflow you are running. Name it after the workflow. Put it in environment variables. Redact it from screenshots, tickets, and logs. A raw credential pasted into a chat channel gets rotated — annoying once, cheaper than tracking who copied it.
Static ISP proxies are pay-per-IP with unlimited bandwidth. Count the stable lines you need by workflow, not by background retries a tool may create.
First stability test is dull on purpose
Connect through the line. Check the exit IP. Run the real workflow. Close the browser. Reconnect. Check the exit IP again. Then try after the machine sleeps and after the job runner rolls over logs. Do this by hand first — you want to see which page actually appears, not only the worker's status string.
When a long session fails, do not swap IPs first. Check for expired cookies, password prompts, two-factor prompts, consent screens, maintenance pages, and changed selectors. Then run a small health probe through the same proxy line — a one-off Python Requests call with the proxies dict is fast enough. If the probe returns the expected exit, the proxy is not the first suspect.
Usage logs see more than the app reports
Application-level metrics are usually incomplete. The app logs the narrow event: five screens clicked, one record saved. The browser also pulled images, polling endpoints, fonts, redirects, analytics, failed responses, and background refreshes that the app never credits. The Proxynade dashboard network logs show host, outcome, latency, and byte totals; usage logs export as CSV. On static ISP those bytes do not change the bill, but the logs still catch loops and retry storms the app summary hides.
Keep a plain-text session record
Workflow name, line ID, expected country, first and last observed IP, browser profile path, last good timestamp, reconnect reason. This ends the argument about whether the proxy moved or the browser state got wiped — which is the only argument that matters when a long-running job stops working at 2 AM.
Static ISP session FAQ
What makes a session fail on static ISP proxies? Most failures split into two causes: the browser state disappeared (deleted profile, expired cookies, two-factor prompt) or the proxy line is misconfigured. Check browser state before assuming the IP changed.
Does static ISP bandwidth count the same as residential? No. Static ISP is pay-per-IP with unlimited bandwidth. Residential lines — Volume at $0.89/GB and Premium at $5.00/GB — bill per transferred byte, including retries and blocked responses.
How do I verify the same IP survives a reconnect? Connect, note the exit IP, close the browser, reconnect, and check the exit IP again through the same proxy line. Do it after the machine sleeps and after the job runner rolls logs — not just on the first clean run.
When should I use sticky residential instead of static ISP? If a 20-minute sticky window covers the whole workflow, use sticky residential. Static ISP is for jobs where the same exit must be there tomorrow without any rotation window.
Session checks
- Name each static line after the workflow that uses it.
- Store cookies, profile path, and proxy line together.
- Verify exit IP after every reconnect, not just the first run.
- Check browser state before rotating the proxy line.
- Export usage CSV to catch retry loops the app hides.