A BugDump report has more in it than most people look at. Here is the whole surface, and a method for using it.
What a report contains
Description — what the user typed. Often the least reliable part, and still the place to start: it tells you what they expected.
Screenshots — what they saw, including any arrows, boxes, text, or blurred regions they added.
Screen recording — where the bug involves a sequence rather than a state.
Voice notes — some users explain in twenty seconds what they would never write down.
Console logs — everything logged during the session, including entries from before the widget was opened. The SDK installs its collector at init, so the error that started the problem is usually captured even though the user reported it minutes later.
Network requests — method, URL, status, and timing for each request. Bodies are included when captureNetworkBodies is enabled.
Session replay — an rrweb reconstruction of the DOM over time. Not a video: a replay of the actual document, which you can inspect.
Actions — clicks, inputs, and navigation, in order. Your reproduction steps, recorded rather than remembered.
Performance timings — page load and resource timing, for the reports that are really about slowness.
Metadata — browser, OS, viewport size, page URL, and the timestamp.
Context — the data your app attached with setContext(), such as the customer's plan or the build they were on, one key per row on its own tab. The tab is there only when your app sent something.
A method
Read the description, then ignore it. It tells you what the user was trying to do. It rarely tells you what broke.
Go to the console next. A red error here usually ends the investigation on the spot. Check the timestamp — an error thirty seconds before submission is a much stronger lead than one at page load.
Then the network log. Look for 4xx and 5xx responses, and for requests that are conspicuously slow. A 500 immediately before the user gave up is your bug. A 200 that took nine seconds is a different bug, and also yours.
Check the viewport. A surprising share of "the button doesn't work" reports are layout problems at a width you never tested. The metadata gives you the exact number.
Use the replay for the ones that make no sense. When console and network are both clean but the user is certain something broke, the replay shows you what they actually did — which is often not what they described.
Then the actions list. It is your reproduction steps, already written.
Why several reports on one task helps
When you attach multiple reports to the same task, you get something a single report cannot give you: the intersection.
Three reports of the same bug across three browsers, two operating systems, and three viewport widths tell you immediately whether it is a browser bug, a responsive bug, or genuinely universal. The common factor across reports is usually the bug.
Reading reports through Claude Code
Everything above can be handed to an agent instead. BugDump's MCP server exposes reports directly to Claude Code — including get_report_telemetry, which pages through the complete console and network history rather than the trimmed summary.
The practical difference: instead of reading a network log yourself, you paste a task ID and let the agent correlate the console error, the failing request, and your source.
See the MCP setup guide.
See also
Working with tasks and the board
Feature toggles and sensitive data