Why you're always logged out of the wrong thing
One dashboard keeps you signed in for months. Another throws you out after twenty minutes of reading. A third logs you out only on the laptop, never the phone. This isn't random, and understanding the machinery underneath makes the difference between fighting your tools and planning around them.
What "logged in" actually means
A website has no memory of you between requests. Every page load is a fresh conversation, and "being logged in" is entirely a matter of your browser presenting a token that the server recognises.
You supply a password once. In exchange the server issues a credential — almost always stored in a cookie — and your browser sends it back with every subsequent request. Logging out means discarding it. Being logged out unexpectedly means it expired, was invalidated, or never got stored in the first place.
Everything that follows is a consequence of how a given site chose to manage that token.
The three lifetimes that matter
Most confusing behaviour comes from one of three overlapping clocks.
Session cookies have no expiry date and are meant to be discarded when the browser closes. This produces the "why am I logged out every morning?" pattern — and also the opposite surprise, because browsers that restore your previous tabs on launch often restore these cookies too. Same setting, opposite outcomes, depending on how you quit the browser.
Persistent cookies carry an explicit expiry — hours, weeks, sometimes a year. This is what a "remember me" checkbox typically switches on. The site decides the duration and you generally can't see it without inspecting the cookie.
Idle versus absolute timeouts. An idle timeout ends the session after a period of inactivity, refreshing every time you act. An absolute timeout ends it a fixed time after login regardless of activity. Banking and infrastructure tools often apply both, which is why you can be typing and still get thrown out — you've hit the absolute limit, and no amount of activity extends it.
An absolute timeout can't be avoided by staying active. If a service logs you out mid-task at what feels like a consistent interval from when you signed in, that's what you're hitting. Save your work before the boundary rather than fighting it.
Why long sessions exist at all
Modern applications often use a short-lived access token — minutes — alongside a long-lived refresh token. Your browser quietly exchanges the refresh token for a new access token in the background, so you stay signed in for weeks while any single leaked token is only briefly useful.
This is a genuine security improvement, and it explains two things you've probably noticed. It's why "sign out of all devices" works properly on some services: they revoke the refresh token, so the next background exchange fails everywhere. And it's why other services take a while to actually cut off a revoked session — the existing access token stays valid until it expires on its own.
Why the durations differ so much
Every product makes its own trade between friction and exposure, and the pattern is consistent enough to predict:
| Type of service | Typical behaviour | Reasoning |
|---|---|---|
| Banking, payments | Short idle timeout plus an absolute cap | Direct financial loss; regulatory expectations |
| Cloud infrastructure, registrars | Moderate, with re-authentication for sensitive actions | High blast radius, but daily-use tooling |
| Analytics, marketing, helpdesk | Weeks or months | Read-heavy, lower consequence, friction hurts adoption |
| Consumer platforms | Effectively indefinite | Any logout is a chance to not come back |
The consequence for anyone managing many dashboards is that you're permanently in a partial state — never logged into everything, never logged out of everything. That unpredictability, more than the raw number of logins, is what makes the work feel heavy, and it's why batching logins by group helps more than trying to stay signed in everywhere.
Step-up authentication
A pattern worth recognising: you're signed in, you go to change a payout destination or delete something, and the site asks for your password again. That's step-up authentication — the session proves you were you at some point, and for a consequential action the site wants proof you're at the keyboard now.
It's good design, and it means a stolen session cookie can browse but not necessarily do damage. It also means the prompt is a signal: if you're asked to re-authenticate for something you didn't initiate, stop and look at what's actually being requested.
Things that log you out unexpectedly
When a session dies earlier than it should, the cause is usually one of these:
- Browser settings clearing cookies on exit. Common in privacy-focused configurations and easy to forget you enabled. Most browsers let you exempt specific sites — do that for the dashboards you use daily rather than turning the protection off entirely.
- Private or incognito windows. Everything is discarded on close, by design.
- Cookie-clearing extensions or cleanup tools running on a schedule.
- Password changes. Many services invalidate all sessions when the password changes — usually correct behaviour, occasionally surprising.
- IP or device changes. Some security-conscious services tie a session loosely to a network or device fingerprint. Switching networks or connecting to a VPN can end it.
- Concurrent session limits. A few services allow only one active session, so signing in on your phone silently ends the one on your laptop.
- Server-side invalidation. After a security incident, a permission change, or a deploy, a service may revoke everything at once.
Device trust and "remember this device"
Separate from the login session, this is a second cookie that tells the site not to ask for your second factor again on this browser. It usually lasts far longer than the session itself — often a month or more.
Two practical implications. It's the reason you can be logged out and still not be asked for a code: the session expired, the device-trust cookie didn't. And it's a real credential in its own right — anyone with that browser profile skips your second factor entirely. Never tick "remember this device" on a shared or borrowed machine, and when a device is lost, look for a "forget all trusted devices" option, which is a distinct action from ending sessions.
Working with the grain
A few habits that reduce the friction without weakening anything:
Note the rough session length in your inventory as you learn it. This converts a recurring surprise into something you can plan around: you'll know that the weekly reporting cluster always needs a fresh login and the daily set usually doesn't.
Use "remember me" on Tier 3, skip it on Tier 1. Long sessions on low-consequence dashboards cost you almost nothing. On your registrar or cloud root, the friction is the feature.
Keep separate browser profiles for separate identities. Cookies are scoped per profile, so two profiles can hold two logins to the same service simultaneously — which beats logging out and back in all day. Covered in the browser profiles guide.
Exempt your daily dashboards from cookie clearing rather than disabling it globally.
Batch by cluster, not by task. Since you can't predict which sessions have expired, stop treating logins as interruptions and handle a whole group in one pass. You pay the context-switching cost once.
When you actually want to end a session
Closing the tab does nothing — the cookie is still there and the session is still valid. Three levels of thoroughness, worth knowing which is which:
- Sign out in the application. Ends that one session properly.
- "Sign out everywhere" or "end all sessions" in security settings. Revokes the refresh tokens too, which is what you want after losing a device.
- Revoke trusted devices — a separate setting on most services, and the one people forget. Ending sessions does not remove device trust, so a recovered laptop can still skip your second factor.
After a lost or stolen device, do all three, then check for tokens and connected apps. Sessions are the visible layer; tokens are the one that outlives everything else.