A screenshot captures the outcome of a browser failure.
It usually does not capture the path that produced it.
By the time a bug reaches another developer, the original browser session is gone. The recipient sees the screenshot, but not necessarily:
- the action immediately before the failure
- the console error that appeared at the same time
- the request that returned HTTP 503
- the browser and page involved
- whether the captured evidence was complete
- whether an attachment changed after the report was created
The obvious response is to record more data.
That creates a second problem: browser sessions contain far more
sensitive information than most bug reports need.
The evidence boundary matters more than the recorder
A browser recorder can observe URLs, form inputs, request headers,
console messages, cookies, DOM state, screenshots, and user actions.
Persisting all of that may produce a detailed replay, but it also creates an artifact that is difficult to inspect, difficult to share, and risky to keep.
For a local bug handoff, I found a smaller boundary more useful:
- a value-free action trail
- relevant console errors
- failed requests and HTTP error responses
- browser identity
- limited page state
- a screenshot
- an explicit capture receipt
The goal is not to recreate everything the user saw. It is to preserve the smallest useful action-to-failure chain.
For example:
click button #7
-> HTTP 503 GET /api/http-error
-> console error: fixture:request-failed
input input #4 (length=14; value never persisted)
submit form
The input action is useful. The value is not.
Recording the character count confirms that an input occurred without
turning the report into a storage location for an email address,
password, token, or other form value.
Redact before persistence
Redaction is strongest when sensitive data never reaches persistent
storage.
That means the capture path should sanitize data before appending it to an event log or report—not after the final report is assembled.
Some practical boundaries include:
- remove credentials embedded in URLs
- redact sensitive query parameters
- redact authorization-like strings
- never record typed form values
- bound dynamic strings by UTF-8 byte length
- visibly mark truncation instead of silently losing data
- expose dropped or corrupted evidence as degraded health
The last point is important.
A recorder should not produce a clean-looking report after it failed to write part of the evidence. Missing evidence is itself evidence about the reliability of the capture.
Keep observations separate from conclusions
Suppose a user clicks Save, a request returns HTTP 503, and an error
message appears.
The recorder can safely report:
A click was followed by an HTTP 503 response and a visible error.
It cannot safely report:
The HTTP 503 caused the visible error.
The events are temporally related, but temporal proximity is not proof of root cause.
A durable bug report should make that distinction explicit. Developers and coding agents can investigate the code afterward, but the recorder should not turn correlation into a confident diagnosis.
Make the artifact independently checkable
A report directory is more useful when the recipient can check it
without reopening the application or browser.
A minimal verification layer can check:
- the report format and compatible version
- safe attachment paths
- declared attachment sizes
- SHA-256 attachment hashes
- capture receipt consistency
- whether the browser shutdown result contradicts the report
This does not prove who created the report. It also does not prove that the reported root cause is correct.
It does detect accidental or deliberate attachment changes and
structural inconsistencies.
Those authenticity limits should be part of the output rather than
hidden in documentation.
Why not use a HAR, Playwright trace, or Sentry?
These tools solve adjacent problems.
A HAR file is a good fit when the primary artifact is network traffic.
Playwright is a good fit after a flow is understood well enough to
automate as a repeatable test.
Sentry and similar observability systems are designed to collect
failures across deployed applications and real users.
DevTools and browser MCP tools are strong choices for live
investigation.
The gap I wanted to address was narrower:
A human can reproduce the local browser bug, but it has not been
automated yet, and the evidence needs to survive the browser session.
That is a handoff problem rather than a testing or monitoring problem.
A small implementation of this approach
I implemented these constraints in an MIT-licensed CLI called
BugBaton.
It launches an isolated Chrome profile on a loopback CDP endpoint,
records one manual reproduction, and writes ordinary JSON, Markdown,
and PNG files.
It requires:
- Node.js 22 or newer
- Chrome, Chromium, or Chrome Canary
It does not require:
- an account
- a cloud service
- a browser extension
- an MCP server
- runtime npm dependencies
- telemetry
The packaged deterministic demo can be run without cloning a repository or providing an existing application:
npm exec --yes --package=bugbaton -- bugbaton demo
The demo only reports success after observing an action, a browser error, and a failed request. Otherwise, it returns an explicit incomplete evidence error.
A saved report can be checked later with:
bugbaton verify REPORT_DIR
The implementation, example report, tests, and design decisions are
available here:
https://github.com/mun-jeong-min/BugBaton
The main question I am still exploring is not how much browser data can be captured.
It is how little data a useful browser failure handoff actually needs.
What would you remove from this evidence boundary, and what would you
still need before trusting the report?
Disclosure: I am the author of BugBaton. I used an AI coding and writing assistant to help edit this article. I reviewed the technical claims, commands, and examples.
Top comments (0)