Support tickets describe being logged out mid-task, sometimes after a few minutes, sometimes after an hour. It never happens in testing. Intermittent authentication failures come from a short list of causes, and most are environmental - they require multiple instances, real load or a specific browser context to appear at all.
01Sessions in memory do not survive anything
Sessions held in a single process are lost on every restart, deployment and scale-down. With multiple instances behind a load balancer, a user authenticated on one instance is unauthenticated on the next request if it routes elsewhere. Locally, with one process and no restarts, this never occurs.
Move session state to a shared store. Sticky sessions are sometimes proposed as an alternative, but they only relocate the problem: the instance still restarts eventually, and everyone bound to it is logged out simultaneously.
| Cause | Pattern | Check |
|---|---|---|
| In-memory sessions, multiple instances | Random, worse with more replicas | Instance count and session store |
| Session store evicting keys | Correlates with load | Eviction metrics on the store |
| Clock drift between servers | Tokens rejected as not yet valid | Time synchronisation |
| Short token lifetime, no refresh | Predictable interval | Token expiry configuration |
| Cookie attributes wrong | Specific browsers or embedded contexts | SameSite, Secure, Domain |
| Deploy invalidating sessions | Clusters at deployment times | Signing key stability |
02The session store may be evicting
If sessions share a cache instance with application data under an eviction policy, sessions are discarded when memory pressure rises. The result is logouts that correlate with traffic peaks - precisely when the system is busiest and the impact greatest.
Use a separate instance for sessions, sized for the maximum concurrent count and configured not to evict. Monitor eviction counts explicitly; a rising eviction metric during peak hours matching logout reports confirms the diagnosis immediately.
03Clock drift breaks token validation
Tokens carry issued-at and expiry claims validated against the receiving server's clock. If one server runs even a minute ahead, tokens it receives may appear to be issued in the future and get rejected. Users hitting that server are logged out while others are unaffected.
Ensure time synchronisation is running on every host and allow a small tolerance - typically thirty to sixty seconds - when validating time-based claims. Containers inherit the host clock, so this is a host-level configuration issue rather than an application one.
| Attribute | Effect if wrong |
|---|---|
| SameSite=Strict | Cookie not sent when arriving from another site |
| SameSite=None without Secure | Rejected by modern browsers |
| Secure on an http origin | Cookie never stored |
| Domain too narrow | Not sent to subdomains that need it |
| Missing Max-Age | Session cookie lost when the browser closes |
04Rotating signing keys logs everyone out
If the token signing secret is generated at startup rather than supplied as configuration, every deployment produces a new key and invalidates all existing tokens. This appears as everyone being logged out at once, correlating exactly with deployment times.
Supply the secret from configuration and keep it stable across deployments. When rotation is required for security reasons, accept both the old and new keys for a transition period so existing sessions survive.
05Instrument the logout, not just the login
Log why a session was rejected - expired, signature invalid, not found in the store, clock validation failed. Without that distinction every case looks identical from the outside and diagnosis relies on guesswork.
Attach the instance identifier and the user's session age. If rejections concentrate on one instance, the problem is that host; if they cluster at a consistent session age, it is expiry configuration. That single field frequently identifies the cause within minutes.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer