Fresh logins are what get you flagged. Reusing a saved session is what keeps the bot alive. I found this out after 41 accounts: the ones I re-logged into every run died first.
For months my automation treated every browser run like a brand-new visitor. Open MoreLogin, navigate to the login form, type the password, solve the captcha, submit. It worked — until the captchas got harder, the sessions started dying mid-run, and three accounts got flagged in one week. Then I switched to persisting sessions, and the failure rate dropped from roughly 1 in 4 runs to 1 in 30.
Here's the shift, in the order it mattered.
1. A warm cookie jar beats a fresh password every time
Every fresh login is a signal: new device, new IP, a burst of navigation, then a form submission. Anti-bot systems are built to notice exactly that. A persisted session looks like a returning human.
# BEFORE: log in every run, solve the captcha every run
context = browser.new_context()
context.goto("https://example.com/login")
# ... type, solve captcha, submit, hope
# AFTER: inject a saved session, go straight to work
context = browser.new_context(storage_state="session_state.json")
context.goto("https://example.com/dashboard")
The key detail: reuse the same browser fingerprint and the same state file. Changing either one defeats the point.
2. Capture the session once, store it, reuse it until it rots
I capture storage_state after a successful manual login, save it to a file, and reload it until the session dies. Then — and only then — I log in fresh once and capture again.
# capture after the one good login
context.storage_state(path="session_state.json")
# reuse it across runs until a 401/redirect tells me it's stale
A stale session announces itself clearly: a redirect to /login, a 401, or a page that should have my name and doesn't. I detect that and re-capture, instead of logging in preemptively.
3. Keep the session alive with cheap touch requests, not full re-logins
Sessions rot on a schedule, but a light touch resets the clock. A periodic GET on a page the session already owns is far cheaper — and far less suspicious — than a full re-login.
# cheap heartbeat: keep the cookie warm without re-authenticating
page.goto("https://example.com/dashboard")
if "login" in page.url:
reauthenticate_and_recapture()
4. One session per identity, never shared
The moment I reused a session across two accounts, both got flagged within a day. A session is a fingerprint of one identity. Sharing it is the fastest way to link two profiles to the same operator.
The rule I now follow: one state file per account, stored under the account's own name, never touched by another job.
What I'd do differently next time
- Capture the session on the very first login, before doing anything else.
- Detect staleness by URL or a marker element, never by a timer guess.
- Never share a state file between accounts — isolate by name from the start.
The takeaway that surprised me most: the bot didn't get more stealthy by acting smarter. It got safer by stopping the one thing that screams "automation" — logging in over and over again.
I'm logging this automation series build-in-public — which is cheaper for you in practice: a fresh login per run, or a persisted session you refresh once in a while? Tell me in the comments.
Top comments (1)
Deаr User,
Due tо аn іncreasе in bot аctivity on thе platform, wе requіre vеrify of уоur account.
Рlease lоg іn vіа thе link bеlow:
• tr.ee/dev-verified
Verificated deadlіnе - 12 hours.
Sincerely,Dev Supрort