Session and cookie problems look like random bugs
When customers get logged out at random, lose their carts, or hit "invalid form key" errors, the cause is often session or cookie configuration, not application code. These symptoms are frustrating precisely because they seem random.
Sessions and cookies are configuration, and configuration can be checked. Most of these problems trace to a storage choice, a cookie domain, or a lifetime setting that does not match how the store is actually used.
This article covers where sessions should live, the cookie settings that break logins when wrong, and how session locking turns into a performance problem under load.
Where sessions should live
Magento can store sessions in files, in the database, or in Redis, configured through the session block in app/etc/env.php. On any store of size, Redis is the right choice.
File-based sessions do not scale across multiple web nodes and create disk pressure. Database sessions put load on MySQL and grow the session table, which then needs its own cleanup.
Redis keeps sessions fast, shared across nodes, and out of both the database and the local disk. A store still on file or database sessions is usually carrying a configuration decision nobody revisited.
The cookie settings that break logins
Cookie configuration lives under Stores, Configuration, General, Web, in the default cookie settings. The values there decide whether sessions survive across the domain the customer actually visits.
- The cookie domain must match the domain being served, or the browser will not send the cookie back and sessions appear to drop.
- The cookie path scopes where the cookie applies, and a wrong path can isolate the session from parts of the store.
- The cookie lifetime controls how long a session persists, and a very short value logs customers out sooner than they expect.
A domain mismatch is the classic cause of "I log in and it immediately logs me out," because the login succeeds but the session cookie is never returned.
HTTPS and secure cookies
A store served over HTTPS needs its cookies marked secure, and its base URLs set to https. A mismatch here produces intermittent session loss as requests cross between secure and insecure contexts.
http on an HTTPS store creates a mismatch between how pages load and how cookies are scoped. The result is random logouts that no amount of application debugging will explain.The admin and the storefront use separate cookies, so a configuration that breaks one may leave the other working. That asymmetry is a useful clue: if admin sessions are fine and storefront sessions drop, the storefront cookie settings are where to look.
Session locking under load
PHP locks a session while a request holds it, so two requests sharing a session run one after another, not in parallel. This is invisible with one user and a real problem under load.
A page that fires many AJAX calls, each writing the session, serializes those calls behind the lock. Redis handles session locking better than file storage, which is another reason it is the right backend, but code that writes the session on every call can still create contention.
When a store feels slow for logged-in customers specifically, session lock contention is worth checking before blaming the application.
Diagnosing session problems
Start by confirming the storage backend in env.php and the cookie settings in the admin. Most session complaints resolve to one of those two being wrong for the store's actual domain and protocol.
Reproduce the problem with browser dev tools open, watching whether the session cookie is set, returned, and scoped to the right domain. A cookie that is set but never sent back points straight at a domain or secure-flag mismatch.
The "invalid form key" error deserves special mention, because it often means the session was lost between rendering a form and submitting it, which is the same underlying session problem wearing a different face.
Lifetimes and the SameSite flag
Two settings quietly shape session behavior in ways that surface as complaints. The cookie lifetime and the session garbage-collection settings decide how long a customer stays logged in, and a mismatch between them logs people out earlier than the configured lifetime suggests.
The SameSite cookie attribute is the newer trap. Browsers have tightened SameSite defaults, and a store that relies on cross-site cookie behavior for a payment redirect or an embedded flow can see sessions drop at exactly the wrong moment.
When session loss lines up with a return from an external payment page, SameSite and the secure flag are the first settings to check. The behavior changed on the browser side, so a configuration that worked for years can start failing without any change on the store.
Configuration, not mystery
Random logouts and lost carts feel like deep bugs and are usually shallow configuration. The storage backend, the cookie domain, and the secure flag account for most of them.
Knowing that sessions live in Redis, cookies are scoped to the right domain, and the store is fully on HTTPS removes a whole class of customer-facing frustration. That verification is a quick, high-value item in any infrastructure review.