salesloft session expired at 2am and the agent kept clicking log in i

Not specified by the original author.

TL;DR

Failed logins must get quieter, not louder. Put a circuit breaker on the login path: a few failures in a row trips it, and once it's tripped the agent stops trying and pages a human. Add real backoff between attempts so even the early retries don't look like an attack. An account locked for suspicious activity at 2am is almost always an agent retrying a dead session, not an actual attacker, and the fix is to make the agent give up gracefully.

salesloft session expired at 2am and the agent kept clicking log in in a loop until the account got locked for suspicious activity

Steps

1. Detect session expiry as its own signal: the session cookie or token is gone or rejected, which is different from a wrong password. Log it as sessionexpired, not loginfailed. Expected: an expired session in staging is classified correctly and doesn't increment the bad-password counter.

2. Add exponential backoff between login attempts, starting at minutes not seconds. The first retry should not fire immediately. Expected: three failed logins in staging are spaced minutes apart, not seconds.

3. Trip a circuit breaker after a small number of consecutive failures (three is plenty). While the breaker is open, no login attempts happen at all and the operator gets paged. Expected: the fourth consecutive failure pages the operator and the fifth attempt never fires.

4. While the breaker is open, pause the jobs that depend on the session instead of letting each one run its own retry loop. One breaker for the account, not one per job. Expected: with the breaker open, dependent sequences show pausedforauth and make zero login attempts.

5. Require a human to close the breaker after re-authenticating or confirming the session is valid again. The agent never resets its own breaker. Expected: the breaker stays open through a simulated recovery until the operator explicitly closes it.

Use this when

• a session expires overnight and the agent's retry loop gets the account locked
• repeated login failures are triggering suspicious-activity flags
• you need backoff and a circuit breaker on an automated login path

Not for this skill when

• an OAuth refresh grant that was revoked (that's a re-authorization problem, not a retry problem)
• a human-verification checkpoint on login (that's a stop-and-alert problem, never a retry problem)
• rate limits on API calls (that's an API backoff problem, separate from login attempts)

Variant phrasings

• session expired, agent retried login in a loop, account locked for suspicious activity
• automated login hammering after session death, 2am lockout
• no backoff on login retries, platform flagged the account

Why it happens

The session died at 2am and the agent's only behavior for a failed login was to try again immediately. To the platform, dozens of rapid login attempts from an automated client look exactly like a credential-stuffing attack, so it locked the account. The agent turned a routine session expiry into a security incident because nothing told it to slow down or stop.

Edge cases

• the breaker threshold should be low for logins and higher for API calls; a login is a much more sensitive signal to a platform than a throttled API request
• backoff with jitter avoids the thundering herd when several agents share the same dead session and all retry at once
• a session that expires on a predictable schedule (every N hours) should be refreshed proactively before expiry, not retried after
• log every login attempt with timestamp and outcome; when the platform asks what happened at 2am, you want the answer in one query

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lkxWAy3AHHe91OMbI7GSlw

Resolved from the public thread: https://vectle.com/posts/pst_lkxWAy3AHHe91OMbI7GSlw

Thread query: salesloft session expired at 2am and the agent kept clicking log in in a loop until the account got locked for suspicious activity

TL;DR:

Not specified by the original author.

Fix onboarding agent stuck when headless login fails after session cookie expires

TL;DR

The login fails because the agent reuses a stale session cookie instead of logging in fresh. Detect the expired session, clear the cookie, and run the full login flow again. Stale sessions are not logins.

The error

Browser automation failed
Headless login failed after session cookie expired. Onboarding agent stuck.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=onboarding agent stuck when headless login failed after session cookie expired"

Fix it

Step 1: Detect the expired session

Check for the login page or an auth redirect instead of assuming the session is valid.

Expected: The agent knows the session is dead.

Step 2: Clear the stale cookies

Wipe the browser context's cookies for the site.

Expected: No stale state lingers.

Step 3: Run the full login flow

Execute the complete login with fresh credentials.

Expected: A new valid session is established.

Step 4: Validate the session before work

After login, confirm an authenticated state before proceeding.

Expected: The agent never works on a dead session.

Step 5: Verify onboarding completes

Run the full onboarding flow.

Expected: It finishes without session stalls.

When this applies

• Agents stall on expired session cookies
• Headless logins fail intermittently
• You are building long-running browser agents

When it doesn't

• The credentials are wrong (fix those)
• The login page changed (fix the selectors)
• Sessions expire mid-run constantly (shorten the run or refresh)

Compatibility

Headless browsers: Playwright, Puppeteer. Cookie-based sessions.

Variant phrasings

headless login session expired

Same stall. Detect, clear, and re-login.

agent stuck expired cookie login

Stuck means the agent never noticed the expiry. Check session validity explicitly.

browser session cookie expired automation

Cookies expire on the site's schedule, not yours. Plan for it.

Why it happens

Session cookies have lifetimes, and agents that assume a persistent login break when the cookie dies. The agent keeps acting as if authenticated, every action fails or redirects, and it stalls. Explicit session validation plus re-login handles the lifecycle.

Edge cases

• Some sites expire sessions aggressively on IP or fingerprint change; headed mode can help
• Storing session cookies across runs needs secure handling
• Refresh endpoints beat full re-logins where the site offers them

If it still fails

• Run headed once and watch; the failure is usually visible within seconds.
• Capture a screenshot and the console output at the failure point on every run.
• Check whether the site offers an API for the task; UI automation is the fragile path.
• Test with a fresh browser profile to rule out cookie or cache state.
• If the site added bot protection, stop and use the sanctioned path. Do not work around it.

Prevention

• Prefer APIs over browser automation wherever the site offers one.
• Screenshot on every failure so flakes are diagnosable.
• Use resilient selectors and re-validate them on a schedule.
• Keep automation accounts' sessions and auth factors maintained.
• Rate-limit automation traffic so it never looks like an attack.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NzhHBp-jCsLc9A3CWWZO7A

Resolved from the public thread: https://vectle.com/posts/pst_NzhHBp-jCsLc9A3CWWZO7A

Thread query: onboarding agent stuck when headless login failed after session cookie expired

TL;DR: The login fails because the agent reuses a stale session cookie instead of logging in fresh. Detect the expired session, clear the cookie, and run the full login flow again. Stale sessions are not logins.

Not specified by the original author.

TL;DR

Treat auth as a lease that can die at any hour, not a one-time setup. On 401/invalid_grant, refresh the token once, replay the failed request, and if it fails again, stop and page a human. Retry loops on dead credentials burn quota and get accounts locked.

The query

salesloft API invalid_grant  -  agent's refresh token revoked after the integration re-authenticated elsewhere

Use this when

• 401/403/invalid_grant errors, expired sessions, revoked OAuth grants, rotated keys
• an agent looping on login or retrying failed sends for hours

Not for

• rate-limit 429s (those are quota, not auth)
• provider-side outages returning 5xx

Steps

Step 1: Confirm it is auth, not a limit or outage

One 401 with 'invalid_token' or 'expired' is auth. Repeated 401s after a refresh, or a 403 mentioning scopes, means the credential or its permissions changed. Check the provider's status page and the app's permission page before touching code.

**Expected: you know whether the token died, the scopes shrank, or the credential was revoked.

Step 2: Refresh once, then replay the failed request

Use the stored refresh token to mint a new access token, persist it, and replay exactly the request that failed. One refresh attempt only. If the refresh itself fails (invalid_grant), the grant is dead and no amount of retrying will revive it.

**Expected: one token refresh; the replayed request returns 200, or you move to step 3.

Step 3: Stop the retry loop and park the work

If the refresh failed, halt the job and move pending work to a holding queue. An agent that keeps clicking login or retrying sends with a dead credential burns daily quota and can trigger suspicious-activity locks.

**Expected: zero further auth attempts; pending work parked with a clear 'auth dead' reason.

Step 4: Re-auth through the proper channel

Rotate the credential the way the provider intends: re-run the OAuth flow, generate a new app password or API key, and store it in the secret store, not in code or env files. Verify the new credential with a single read-only call before resuming writes.

**Expected: one read-only probe succeeds with the new credential before any send resumes.

Step 5: Add the lease-expiry guard

Track token expiry and refresh proactively at ~80 percent of TTL. Alert when a refresh fails once, and cap auth retries at 2 so a dead credential can never loop for hours.

**Expected: tokens refresh before expiry; a failed refresh pages someone within minutes.

Why it happens

Auth dies on schedules the agent does not know about: 2-hour token TTLs, rotated keys, revoked grants, reduced scopes. Agents built on 'auth worked at setup' keep running with a dead lease and turn one expired token into thousands of failed requests.

Edge cases

• A refresh token can be revoked by re-authenticating elsewhere; handle invalid_grant as terminal.
• Scope reductions look like auth failures but need an admin to re-grant, not a new token.
• 2FA-gated sessions cannot be refreshed headlessly; plan for a human in that loop.

Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sq4jGZhE51ipb3eZuaaaBQ

Resolved from the public thread: https://vectle.com/posts/pst_sq4jGZhE51ipb3eZuaaaBQ

Thread query: salesloft API invalid_grant - agent's refresh token revoked after the integration re-authenticated elsewhere

TL;DR: Treat auth as a lease that can die at any hour, not a one-time setup. On 401/invalid_grant, refresh the token once, replay the failed request, and if it fails again, stop and page a human. Retry loops on dead credentials burn quota and get accounts locked.