What we capture with every bug report

The difference between a bug report that gets fixed in an hour and one that rots in a backlog is almost never the severity of the bug. It is the quality of the context. A developer who can reproduce an issue on the first try will usually just fix it; a developer who cannot reproduce it will defer it, and deferred bugs have a way of becoming permanent residents.

That is why every report submitted through the widget carries a standard set of context automatically. This post walks through each field: what it is, why it is captured, and how to actually use it during triage and debugging.

Title and description: the human half

The user provides two things — a short title and a free-form description. Deliberately, that is all we ask of them. Every additional required field measurably reduces submission rates, and a bug report you never receive has zero value regardless of how structured it might have been.

In practice, titles work best as symptoms ("Export button does nothing") and descriptions work best as narratives ("I selected March, clicked Export, and nothing downloaded. Tried twice."). During triage, read the description looking for three things: what the user did, what they expected, and what happened instead. Even terse descriptions usually contain at least two of the three.

Page URL: the where

Every report records the full URL of the page the user was on when they opened the widget. This single field eliminates the most common back-and-forth question in bug history: "which page were you on?"

The URL often carries more diagnostic weight than teams expect. Query parameters reveal filter states, IDs in the path reveal which record was being viewed, and hash fragments reveal which tab or section was active. When a report says the table renders blank and the URL shows ?filter=archived&sort=custom, you frequently have your reproduction recipe before reading the description.

Viewport size: the layout context

The report includes the browser viewport dimensions at submission time. For layout and responsive-design bugs, this is the critical field. A "button is unclickable" report means one thing at 1920x1080 and something entirely different at 375x667, where the real story is usually an overlapping element or an untested breakpoint.

A practical habit: when a visual bug arrives, open your dev tools, set the viewport to the exact reported dimensions, and navigate to the reported URL. A large share of "cannot reproduce" layout bugs reproduce immediately once you match the viewport.

User agent: the environment

The user agent string identifies the browser, browser version, operating system, and device class. It is the field that resolves every "works on my machine" standoff. Safari-specific date parsing, a flexbox behavior that changed between Chrome versions, an input quirk on Android — none of these are diagnosable without knowing the environment, and all of them are routine once you do.

You do not need to be a user-agent expert to benefit. Just compare: does this bug come from one browser family, or several? A bug reported only from Safari is a compatibility bug until proven otherwise. A bug reported across browsers is in your code.

Screenshot or video: the optional evidence

If media capture is enabled on your widget, users can attach a screenshot or a short video. For visual defects, a screenshot typically communicates more than any paragraph of description. For interaction bugs — things that happen in sequence, like a dropdown closing prematurely — video is decisively better, because it captures timing and order that users struggle to narrate accurately.

We keep media optional because requiring it would suppress submissions, but when it arrives, treat it as the highest-signal artifact in the report.

Timestamp: the when

Every report is timestamped. This matters more than it seems: it lets you correlate reports with deploys, incidents, and error spikes in your monitoring. Three reports about a broken form, all submitted within an hour of Tuesday's release, tell a very clear story about where to look first.

Reading a report like a detective

Put together, a complete report answers the reporter's questions before you have to ask them: what happened (title, description, media), where (URL), in what environment (viewport, user agent), and when (timestamp). The routing integrations carry all of it — the Slack message and the Trello card both include the full context, so whoever picks up the report starts with everything.

The result is a quiet but real shift in how bugs move through a team: less interviewing, more reproducing, faster fixing. Context, captured automatically, is what turns a complaint into a work item.