Ideas, tutorials, and updates from our team.
Error tracking for a small web app comes down to four things: catch what breaks, group the repeats, read the stack in your own code, and keep the minute before the crash. How each one works in the browser, what to throw away, and when you need a full monitoring tool.
How session replay works, what it captures, and why pairing it with console and network logs turns vague bug reports into diagnosable ones.
What separates a bug report that gets fixed from one that gets closed as 'cannot reproduce' — structure, context, and a practical checklist.
Users can't send you their console. How client-side capture works — rolling buffers, network hooks, filtering — and how to get it with one script tag.
A systematic approach to bugs you can't reproduce — the usual causes, the context that resolves them, and how to stop them recurring.
"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.
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.
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.