Debug the web path

Inspect browser state

Check cookies, local storage, IndexedDB, cache, service workers, and an isolated profile without clearing evidence first.

10 minute lesson

~~~

“It fails for me but works for everyone else” is usually not the code. It is the state the browser accumulated. Persistent browser state can make one user fail while a clean profile works: an old session cookie, a service worker serving last week’s build, a cached API response.

The reflex to resist is clearing everything immediately. Compare state before deleting it — a wiped profile that suddenly works tells you state was involved, but destroys the evidence of which state.

Compare, then bisect the state

Open a private window or a fresh profile and run the exact reproduction from your card. Record a controlled comparison:

normal profile: failure
private profile: works
cookie difference: old session cookie
service worker: active version 12
cache: response served from disk

Now you have a bounded suspect list. Use the DevTools Application panel to inspect each category: Cookies with per-cookie expiry, Local storage, IndexedDB, Cache storage, Service workers. Check ownership and expiry — a cookie scoped to the parent domain, set long ago by a different subdomain, is a classic invisible culprit.

Remove one state category at a time and rerun the exact reproduction:

1. unregister the service worker  -> still fails
2. clear cache storage            -> still fails
3. delete the session cookie      -> works

The bug is now specific: the app mishandles a stale session cookie instead of redirecting to login. That is a fixable code path. “Clear your cookies” was never the fix — it was the symptom eraser, and the next user with an old cookie hits the same wall.

Service workers deserve extra suspicion

An active service worker can serve every asset and API response from its own cache, making the site immune to your deploys. The Application panel shows the active version; check “Update on reload” to force fresh fetches while you test. If the failing user runs worker version 12 and everyone else runs 14, you have found the mechanism.

Clearing all site data may hide the cause and log the user out. Preserve evidence, and use a disposable account when the reproduction needs real login state.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →