All sessions invalidated: symptoms, cause, and the test that catches it

Symptoms

Root causes

1. stage: config A hotfix for TLS handshake errors changed the secret key used to validate access tokens during a configuration clean-up, so every existing token failed validation.[2]
2. stage: release-process A rolling deployment moved session storage to a new cache while instances updated at different times, so a session created on one instance was missing on the next.[1]
3. stage: code A framework update switched session cookies to an encrypted format with a SHA256 digest, so old and new instances could not read each other's cookies during the rolling deployment.[3]
4. stage: code An edge worker script that parses the session cookie could not read the new format and treated requests as signed in without a valid session.[3]

Public examples

1. [1]Phrase, 2026-02-23. A deployment migrated session storage to a new caching solution while application instances were updated at different times, so instances used different session stores and UI users in the EU region were repeatedly logged out. primary Performance Disruption of Phrase TMS CAT Web Editor and Project Management (EU) on January 29, 2026 between 4:56 PM CET and 5:46 PM CET
2. [2]Mews, 2025-04-11. A hotfix for a TLS issue changed a secret key during a configuration clean-up, which invalidated every logged-in session on Android and web admin and forced all users to log in again. primary Login issue on Mews POS app
3. [3]Organization for Transformative Works, 2024-10-07. A new Archive of Our Own release changed session cookies to an encrypted format and switched cookie digests from SHA1 to SHA256 as part of a Rails update, which during a rolling deployment produced Session Expired errors and forced logouts. primary AO3 elevated "Session Expired" errors

Practitioner sources cited for symptoms

4. [4]Can Olcer, 2021-10-29. A developer describes a Rails app that logged out all users after every deployment because the hosting platform set a new secret_key_base on each deploy, so existing session cookies could not be decrypted. practitioner Rails: Prevent users from logging out after each deployment

Test classes that catch it

Risk

Pre-release checklist

• PR-01Compare the hash of the token secret key in the release configuration with the one in production and block the release on any difference. config
• PR-02Confirm that the platform does not generate a new session secret on each deploy by checking that the variable is set explicitly in production. config
• PR-03Confirm that every instance in the target environment points at the same session store before the rollout begins. config
• PR-04Log in on the current release, deploy the new release to half of the instances, and confirm the same session is accepted on both halves. e2e
• PR-05Send a session cookie issued by the current release through the edge worker script and the new release and confirm both read it as a valid session. e2e
• PR-06Halt the canary when token validation errors per minute exceed the pre-deploy rate. canary
• PR-07Hold the canary at a small share of instances until the forced logout rate stays at its pre-deploy level for a full session lifetime. canary

What catches this: catalogue entries

Listed because their own documentation or site names configuration and environment tests, end-to-end tests, canary and progressive delivery checks on the verification date. Alphabetical. Not a recommendation.

Related incidents

• Password reset link broken Password reset emails link to a wrong or expired route after a routing change.
• Flag enabled for wrong segment A feature flag targets the wrong users, region or percentage after a rule edit.
• SSO login broken Single sign-on fails after an identity provider, certificate or callback URL change.
• API key rotation breaks integrations A key rotation invalidates partner integrations that were not notified.
• Autoscaling policy misconfigured A scaling change fails to add capacity or scales to zero under load.

Questions