'Works on my machine': the diagnostic checklist

You file a bug. The checkout button does nothing on https://staging.example.com/checkout. Twenty minutes later the ticket comes back: "Works on my machine." Now you are in an argument about whether a bug exists, and neither of you is testing anything.

Here is the useful reframe. You are both right. The code behaves differently on two machines, so something about the two environments is different — and there are only about nine things it usually is.

Short version

• "Works on my machine" is not a disagreement. It is a clue that two environments differ.
• Nine differences explain nearly every case: build, cache, flags, role, data, network, extensions, timezone, cookies.
• Check them in that order — the first three cover most of it.
• A clean profile in incognito mode with cache disabled rules out three at once.
• Capture the environment when you report, not when you are challenged.
• If it still cannot be reproduced after all nine, it is likely a race condition.

---

The one-minute pre-check

Three quick facts resolve a surprising share of cases. Put them in the ticket and the conversation usually ends there.

1. The exact URL, including the environment. https://staging.example.com/checkout and https://app.example.com/checkout are not the same app.
2. The account you used, for example [email protected], and its role.
3. The exact time, with timezone. 2026-06-29 14:32 UTC. This lets a developer match your report against server logs and deploys.

If a developer cannot reproduce and one of those three is missing, that is the first thing to fix.

---

1. Build version

The difference: you are running different code.

This is the most common cause. The developer fixed it an hour ago, or you are on a preview deploy from a different branch, or your tab has been open since yesterday's build.

How to check:

1. Hard refresh the page. Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on Mac.
2. Find the build identifier. Most apps expose one — a <meta name="build"> tag, a version in the footer, or a global you can read in the console with window.__APP_VERSION__.
3. Compare it with what the developer has. If they differ, stop here.

Write it in the ticket: "Build 2026.06.29-a7f3c21 on staging."

---

2. Cache

The difference: your browser is serving old files it saved earlier.

Browsers store JavaScript, CSS, and images to load pages faster. After a deploy, you can end up running new HTML with old JavaScript, which produces strange behaviour nobody else sees. A service worker — a script that sits between the page and the network and can serve saved responses — makes this worse, because it survives a hard refresh.

How to check:

1. Open DevTools (F12), go to the Network tab, and tick Disable cache. Keep DevTools open — the setting only applies while it is.
2. Reload and reproduce.
3. If it now works, it was cache. Note that in the ticket rather than closing it — real users will hit the same thing.
4. For service workers: Application tab → Service Workers → Unregister, then reload.

Testing in an incognito or private window covers cache, extensions, and cookies in one step. It is the fastest single check on this list.

---

3. Feature flags

The difference: the feature is switched on for one of you and off for the other.

A feature flag is a switch that turns part of the product on or off without deploying new code. Flags are often set per environment, per user, or per percentage of traffic. Two people on the same build can see two different products. This is the cause that wastes the most time, because everything else looks identical.

How to check:

1. Find where your app exposes flags: a /debug or /admin/flags page, a window.flags object in the console, or the dashboard of your flag tool.
2. Compare the flag values for your account and theirs — not just the environment default. Percentage rollouts assign users individually.
3. Check for flags scoped to internal staff. Developer accounts are frequently in an "internal" group that gets everything early.

Write it in the ticket: "Flag new-checkout-flow is true for [email protected] on staging."

---

4. User role and permissions

The difference: your account is allowed to do different things.

Developers usually test as an admin, because it is convenient. Admins skip permission checks, see extra fields, and often bypass onboarding and plan limits. A bug in the read-only viewer experience is invisible to them.

How to check:

1. State your role in the ticket: "Logged in as a Viewer on the Free plan."
2. Ask the developer which role they used. In most "cannot reproduce" cases involving missing buttons or blank screens, they used an admin account.
3. Re-test as an admin yourself. If the bug disappears, you have found the boundary — that is useful information, not a failed report.

Plan tier belongs here too. Free, Pro, and Enterprise accounts often run different code paths.

---

5. Account data

The difference: your data hits a case theirs does not.

This is the single most common cause of a genuinely reproducible bug that a developer still cannot see. Their test account has three orders; yours has 1,200. Their customer names are Test Test; yours is Ana María O'Brien-Ştefan.

Data shapes that break things:

• Empty — zero records, so a list or chart has nothing to render
• Large — thousands of records, hitting pagination or timeouts
• Long strings and special characters — apostrophes, accents, emoji, right-to-left text
• Nulls — an optional field never filled in, producing TypeError: Cannot read properties of undefined (reading 'name')
• Old records — created before a schema change, missing newer fields

How to check: give the developer your exact account and one record ID. "Reproduces on [email protected], order ORD-48213 — it has 3 refunded line items."

---

6. Network conditions

The difference: their connection is fast and stable, yours is not.

Race conditions hide on fast connections. A page that loads its data in 80ms on office wifi can break at 900ms on a phone, because two requests come back in a different order than the code assumed. Corporate networks add proxies, VPNs, and firewalls that block or rewrite requests.

How to check:

1. DevTools → Network tab → the throttling dropdown (usually "No throttling") → choose Slow 4G.
2. Reproduce. Many timing bugs appear immediately.
3. Look at the Network tab for requests in red, or status codes in the 400s and 500s.
4. If you are on a VPN or corporate wifi, try again without it. Blocked third-party domains can break analytics, payment widgets, and fonts.

---

7. Browser extensions

The difference: something in your browser is changing the page.

Ad blockers, password managers, privacy tools, and grammar checkers all modify pages or block requests. They cause real failures that exist only for the people who have them installed.

How to check:

1. Open an incognito window. Most extensions are disabled there by default.
2. If it works in incognito, re-enable extensions one at a time until it breaks.
3. Name the culprit in the ticket. "Only reproduces with uBlock Origin enabled — it blocks the request to js.stripe.com."

An extension-caused bug is still worth reporting. If a common ad blocker breaks your checkout, your users are affected, and "works without extensions" is not a fix.

---

8. Timezone, locale, and clock

The difference: dates, numbers, and text render differently for you.

Dates are the classic. A booking that shows as 29 June in London shows as 30 June in Auckland, and a date-only field stored as UTC can shift by a day depending on where you are standing.

Locale affects more than dates: number format (1,234.56 versus 1.234,56), date order (03/04/2026 is March 4 or April 3), text length (German labels are often 30% longer and break layouts), and sort order for accented characters.

How to check:

1. Report your timezone and locale: "macOS, Europe/Berlin, browser language de-DE."
2. Read them from the console with Intl.DateTimeFormat().resolvedOptions().
3. Try again with your system set to UTC and en-US. If the bug disappears, it is a locale bug.
4. Check your system clock. A machine several minutes out of sync can fail token validation and produce mysterious logouts.

---

9. Cookies, sessions, and local storage

The difference: state saved in your browser from earlier sessions.

Your browser holds cookies, localStorage, and sessionStorage — small pieces of saved data. A value written by a version of the app from three months ago can still be there, in a shape the current code does not expect. Common symptoms: a stale authentication token, a saved filter that hides all the data, a dismissed banner that stays dismissed.

How to check:

1. DevTools → Application tab → Storage → Clear site data. This removes cookies, storage, and caches for that site.
2. Log in again and reproduce.
3. If it works after clearing, the bug is real and affects any long-standing user. Say so: "Only reproduces with existing storage. Clearing site data fixes it, so it affects returning users, not new ones."

Third-party cookie blocking belongs here too. Safari and Firefox block them by default, which breaks embedded widgets and some login flows that work fine in Chrome.

---

The comparison table to paste into the ticket

When a bug is bounced back, ask the developer to fill in their column. Nine rows, two minutes, and the mismatch is usually obvious.

Most of these values are already sitting in the browser when the bug happens. Capturing them at that moment — which is what browser-based reporting tools such as Crosscheck do automatically alongside the screenshot, console output, and network requests — means you are comparing recorded facts rather than reconstructing them from memory a day later.

---

If none of the nine explain it

You are probably looking at a race condition — a bug that depends on the order two things finish in, which changes run to run. Signs: it happens roughly one time in five, it is more common on a slow connection, and it goes away when you step through slowly.

What helps: record a video with DevTools open so timing is visible, note how many attempts failed ("4 of 20"), and try it with Slow 4G throttling on, which often turns "sometimes" into "always".

---

Frequently asked questions

What should I do first when a developer says they cannot reproduce it? Send the nine-row table with your column filled in, and ask for theirs. It reframes the conversation from "does this bug exist" to "what is different", which is answerable.

Should I still report a bug that only happens with my extensions enabled? Yes. Name the extension in the report. Popular ad blockers affect a large share of real users, so it is a genuine defect even though the cause is external.

Is incognito mode enough on its own? It covers cache, extensions, and stored cookies in one step, which is three of the nine. It does not cover build, flags, role, data, network, or locale.

How do I find the build version if the app does not show one? Ask for it to be added — a <meta name="build"> tag or a version string in the footer costs nothing and saves hours. Until then, note the exact time of your test so it can be matched to the deploy log.

The bug disappeared after I cleared site data. Should I close the ticket? No. Change the description instead. It now reproduces for users with existing browser state, which is most of your real users, and that is more serious than a bug affecting only new ones.