How to capture browser console errors for a bug report

Open a ticket that says only “the page is blank,” and the first question back will be “what does the console say?” The console and the network log are where web bugs confess — the uncaught exception, the 500 hiding behind a spinner, the CORS rejection. The problem isn’t finding them; it’s getting them into the ticket in a form that survives. Here’s the by‑hand route, and the automatic one.

The console, by hand

In Chrome, DevTools opens with Cmd‑Option‑I (the Console tab is one click away in the tab strip). Safari keeps it behind the Develop menu — enable it once in Advanced settings. Firefox calls it the Web Console, under the same wrench‑and‑woodgrain area you already know.

What to take, in order of usefulness:

1. The red lines. Uncaught exceptions and errors, with the stack trace expanded once so the file and line number are visible.
2. The network failures. Switch to the Network tab, reproduce the bug once, and look for red rows — a 4xx or 5xx with a request payload tells the backend team more than a paragraph of prose.
3. The state around it. The URL, whether you were logged in, and the timestamp — logs get correlated against server logs by time.

Right‑click in the console and use “Save as…” to export the full session as a file, and export the network log as a HAR from the Network tab’s export button. Text files beat screenshots: they’re searchable, and they don’t rot when the font is too small to read.

The problem with doing it by hand

The manual route has three failure modes, and every QA person has hit all of them. You forget to open DevTools before reproducing, so the console missed it. You reproduce, capture, and then find the screenshot is unreadable at ticket scale. Or the console is clean but the network tab has the crime — and you copied from the wrong tab.

The deeper cost is context switching: you’re mid‑thought about the bug, and now you’re operating a boat. Bugs reproduce on their own schedule; tool fumbling between you and the repro is where evidence dies.

The automatic route

Snapbak ships with a paired Chromium extension that closes the gap: when you capture a bug, the extension attaches the console errors and failed requests from that same page session to the recording — no DevTools visit required. The repro steps draft as Markdown from the clicks you actually made, so the report structure fills itself while the evidence is still fresh. The honest disclosure: I make Snapbak, and this is the workflow it was built for — weight that accordingly.

The by‑hand skill is still worth having. The extension covers Chromium; Safari and Firefox bugs still start at the Develop menu and the Web Console, and a developer who can read a HAR export is never stuck.

One habit worth keeping

Whatever the tool, reproduce the bug once after capture is running. The most common bad ticket isn’t missing evidence — it’s evidence of the wrong moment: the console captured after the state already settled, the network log from a page that had already loaded its failures. Capture first, then break it on purpose.

Snapbak is free for the first 100 users: download it, pair the extension, and let the next blank page file its own evidence.