What to Do With a Bug Report You Can't Reproduce
A systematic approach to bugs you can't reproduce — the usual causes, the context that resolves them, and how to stop them recurring.
Ideas, tutorials, and updates from our team.
A systematic approach to bugs you can't reproduce — the usual causes, the context that resolves them, and how to stop them recurring.
A third-party widget that ships 450 KB to every visitor has to justify it. Ours couldn't. Here's the measurement, the fix, and the thing about defer that turned out to be wrong.
A UAT round produces a spreadsheet with sixty rows, half of them unactionable. The problem is rarely the testers. It's that the reporting channel throws away the evidence at the exact moment it exists.
MCP turns your product into something an AI agent can read. That part is easy. The hard part is designing tools an agent uses correctly on the first try — which turns out to be a different discipline from designing a REST API.
"Cannot reproduce" is not a property of the bug. It is a statement about the difference between two machines. There are only about eight such differences, and each one leaves a distinct fingerprint.
Every team writes a bug report template. Most are ignored within a month, because they ask people to do work a browser could do for them. Here's a template worth keeping — and the case for deleting three quarters of it.
DevTools is open on the wrong machine. Here's how to instrument console, errors, fetch, and XHR so a user's browser can tell you what actually happened — and the traps that make naive implementations break the page they're monitoring.
Separating reports from tasks is the small structural decision that keeps a bug inbox from becoming a graveyard — and turns duplicate reports into your best debugging asset.
Session replay has a reputation problem, most of it earned. Here's how we use it — scoped to a report, redactable by the user, and off with one line.
We shipped an MCP server so Claude Code can pull bug reports, console logs, and network traces on its own. The result is a debugging loop where you never open the dashboard.
A tour through every signal the BugDump widget collects, why each one earns its place, and which ones actually solve bugs.
Every developer knows the exchange. A user says something is broken, you ask which browser, and by the time they answer you've lost an hour. We got tired of it.