2FA code went to a phone nobody checks - the agent's Sales Navigator session died and prospecting stopped for a...

TL;DR

The second factor has to reach someone who is actually on call. Move the 2FA delivery to a channel the on-call rotation monitors, like a shared authenticator setup or a number that forwards to whoever is on duty. Then add a session-health check that runs on a schedule and pages someone the moment the session dies, instead of discovering it Monday morning. A session that dies Friday night and isn't noticed until Monday is a monitoring failure, not just a 2FA failure.

2FA code went to a phone nobody checks  -  the agent's Sales Navigator session died and prospecting stopped for a weekend

Steps

1. Move the second factor off the forgotten phone and onto something the on-call rotation can reach. Whoever owns the account owns keeping that channel working, and it gets tested monthly.

Expected: a test login completes the 2FA step from the on-call channel with no scrambling.

1. Add a lightweight session-health check that runs every hour: load one authenticated page and confirm the session is alive. Log the result.

Expected: the health check log shows an unbroken series of alive results, and a killed session flips the next check to dead.

1. Page the on-call operator the moment a health check fails, with the account and the last-known-good time. Don't wait for the next business day.

Expected: killing the session in staging pages the on-call within the hour, not on Monday.

1. Define the recovery runbook: operator re-authenticates in a real browser, confirms the session, and the agent resumes. Write it down before you need it at 11pm on a Saturday.

Expected: a fresh operator follows the runbook and restores the session with no guesswork.

1. After recovery, review why the session died: was it a real expiry, or did something trip it? Fix the cause so the next weekend isn't a repeat.

Expected: the post-incident note names the cause and the preventive change, not just 'session restored'.

Use this when

• a session dies because the 2FA code goes somewhere nobody monitors
• an outage sits undiscovered over a weekend because nothing checks session health
• you need on-call-friendly second-factor delivery for agent-owned accounts

Not for this skill when

• a human-verification checkpoint the agent must not attempt to solve (that's a stop-and-alert problem)
• a revoked OAuth grant (that's a re-authorization problem)
• a password that expired (that's a credential-rotation problem)

Variant phrasings

• 2FA code to an unchecked phone, session died, prospecting down all weekend
• nobody noticed the dead session until Monday, no health check existed
• second factor unreachable, agent couldn't re-authenticate on its own

Why it happens

The session needed re-authentication, the second factor went to a phone nobody monitors, and nothing was watching the session's health. Each failure alone would have been a minor hiccup; together they meant the session died Friday and nobody knew until Monday. The agent had no way to complete 2FA itself, which is correct, but nobody had built the human side of the loop either.

Edge cases

• rotating the on-call schedule means the 2FA channel handoff has to be part of the rotation, not tribal knowledge
• some platforms limit how often you can re-verify; burning verifications on health checks can cause the very lockout you're trying to avoid, so keep the check read-only
• a health check that logs in fresh every hour looks like suspicious activity; check the existing session, don't create a new one
• if the account owner leaves the company, the 2FA channel and the runbook need a new owner the same day, not when the next session dies

Provenance

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