"Works on my machine" is the most misunderstood phrase in software development. It's treated as a developer excuse — a way of dismissing a valid bug report. In reality, it's almost always a literal statement of fact.
The developer genuinely can't reproduce the bug. Not because they're not trying, but because they don't have the same context as the user who filed the report.
What the Developer Doesn't Have
When a bug is reported with a screenshot and a description, the developer doesn't have:
- The user's data: The bug might only occur for users with specific account states, permissions, or data configurations. The developer's test account doesn't have those attributes.
- The user's navigation history: The bug might require arriving at the page via a specific route, with specific URL parameters, or after specific previous steps.
- The API response: The bug might be caused by a specific API response — an edge case value, a null field, an unusual data shape. The developer's requests return different data.
- The browser state: The bug might depend on cached data, service worker state, or local storage values that exist for the user but not the developer.
Without any of these, reproduction is impossible. "Works on my machine" isn't an excuse — it's the inevitable result of trying to reproduce a bug with incomplete information.
The Real Solution
The solution to "works on my machine" isn't to ask for more information from the reporter — reporters rarely know what information is relevant. The solution is to capture the complete context at the moment the bug occurs, automatically.
A bug report that eliminates "works on my machine" contains:
Page State Snapshot: The complete DOM at the moment of the bug. The developer opens it in their browser and sees the exact page state — the user's data, the rendered components, the loaded content. They don't need to reproduce it; they're looking at it.
Full API Payloads: The complete request and response bodies for every network call that occurred. The specific API response that caused the rendering failure is there, exactly as the server returned it.
User Context: Who was the user? What plan are they on? What ID? Attached automatically to every report.
With this information, "works on my machine" is no longer a possible response. The developer has the state. They have the data. They have the API response. They can diagnose the bug without reproducing it.
The Economics of "Cannot Reproduce"
17% of bug tickets are closed as "cannot reproduce." These aren't fixed bugs — they're deferred bugs. They keep affecting users. They keep getting reported. They accumulate technical debt.
Each "cannot reproduce" closure represents:
- The developer's time spent trying to reproduce (1-2 days on average)
- The reporter's time re-reporting when the bug recurs
- The ongoing user impact of an unfixed bug
- The trust damage from users who see their reports ignored
Eliminating this category — through better capture — removes a significant operational overhead. With bugs per developer up 54% in 2026, that overhead is growing.
Implementation
SnagRelay captures page state snapshots automatically on every bug report. The developer gets a link in their ticket — click to open the exact page state in their browser. Combined with full API payloads and the error trace, "works on my machine" becomes a phrase your team no longer uses.
Further reading:
