Short answer: For a server-rendered Go login, keep session creation, verification, refresh, and logout under one server-side policy, then make password recovery revoke old sessions and emit an audit trail before it creates a new one.
The page reaches on-call as a symptom, not a diagnosis: a learner completes /forgot-password, lands on /login again, and support can't tell whether the old browser session was revoked. The least complex design that survives the audit is an opaque cookie backed by a server-side session record, with recovery tokens kept separate from login sessions. That choice does add a stateful lookup to authenticated requests. It also gives the platform team a place to enforce expiry and revocation without trusting the browser to report its own status.
No magic here.
The page starts at the end of the audit chain
The first alert should describe the user-visible control that failed: password recovery completed, yet session revocation did not complete within the authorization-change SLO. A raw rise in 401 responses isn't enough because it mixes expired cookies, revoked sessions, invalid credentials, and application mistakes into one noisy count. The useful page carries a correlation ID, the affected flow, and the oldest incomplete state transition; it does not carry a password, recovery token, or raw session identifier.
