Turn DevTools Into a Bug Evidence Kit

Stop Chasing "Can't Reproduce" — Capture Evidence Instead

The biggest time sink in bug triage usually isn't the fix itself — it's the back-and-forth over reports that can't be reproduced. Reporters rarely repeat the exact same steps, and by the time you do reproduce it, the state has often changed. There's one habit that fixes this: open DevTools the moment you notice something's wrong, not later when you're debugging. Treat it as an evidence-capture tool, not just a debugging one — the goal is to preserve "what was happening at that moment" in a form someone else can read afterward.

Console — Preserve the Order Errors Occurred In

The Console panel only shows logs from while it's open, and they vanish on navigation. The moment you spot a bug, do this before you touch anything else:

• Turn on Preserve log from the gear icon (top-right of the Console panel) so logs survive page navigation
• After reproducing, right-click the full log and choose Save as... to export it to a file
• Capture stack traces expanded, not collapsed — a screenshot of a collapsed trace is useless for root-causing

What matters isn't just that an error happened, but the order errors appeared in. It's common for a first error to trigger a second one downstream.

Network — Export a HAR to Preserve the Full Picture

Plenty of bugs that look like UI issues turn out to be backend anomalies. The Network panel's Export HAR saves every request, response, and timing to a single file.

Three Things to Check

• Status codes — anything outside the 200 range mixed in
• Response times — delays creeping toward a timeout
• Recent request history — go back a few minutes before the bug was noticed

In one report, a user described a UI bug: "drag-and-drop on the kanban board won't update status." The automatically captured network log showed two consecutive errors to an unrelated API roughly a minute before the report was filed. The drag-and-drop code was untouched — the real cause was a brief backend outage that had already resolved by the time anyone looked. If that log had depended on someone manually capturing it, the report would have read only as "drag-and-drop is broken," and a developer would have kept searching for a UI bug that didn't exist.

Application — Where to Look When State Is the Suspect

Bugs that "only happen for this one user" usually trace back to local state.

• Copy the relevant Local Storage / Session Storage keys before they get overwritten
• Check cookie expiry and the SameSite attribute — especially important for login-related bugs
• Check whether a Service Worker is serving a stale cached version (try Update under Application > Service Workers)

Catching Intermittent Bugs with Conditional Breakpoints

For low-reproduction-rate bugs, an unconditional breakpoint just wastes your time. Right-click the line in the Sources panel, choose Add conditional breakpoint, and enter an expression (e.g. items.length === 0) so execution only pauses when that condition is true. If you want to log a value without halting execution at all, a Logpoint lets you trace values while the normal flow stays intact.

How Bugoon Handles This

Bugoon's widget automatically attaches recent Console logs and network errors to every bug report at submission time (error-collector.ts). The parts of "evidence capture" described above — preserving Console output, catching network anomalies — are already baked into the report before the reporter even thinks about it. Developers can start investigating from first-party evidence the moment a report arrives, without waiting on reproduction steps. Manually mastering DevTools and automating that same discipline for non-engineer reporters come from the same underlying problem.