Bug Report is a Chrome extension and team workspace for QA. You record a bug once; it writes the report (title, steps to reproduce, actual result, environment) and keeps the console logs, network requests, screenshots and an optional video. Developers press Replay and the same steps run live in their own browser.

How is a live replay different from a screen recording?

A screen recording is a video you have to watch and scrub through. A live replay performs every recorded click, typed value and page change again in the developer's own browser, step by step, with Back, Forward and Pause, so they can open DevTools and inspect the bug while it happens.

How is Bug Report different from Jam, Marker.io or BugHerd?

Those tools capture a bug well: a screenshot or video, and in some of them the console and network. Bug Report captures the same evidence, then goes one step further: the developer presses Replay and the recorded steps run again on the live site in their own browser, and checks QA added while recording say whether the bug is reproduced. The comparison page lists the differences row by row.

Which browsers does Bug Report work in?

Recording works in Google Chrome and in Chromium browsers such as Microsoft Edge and Brave. The report page, the shared links and the team dashboard work in any modern browser.

Does it capture console errors and network requests?

Yes. Every console message, JavaScript error and network request (method, status, headers, request and response bodies for fetch and XHR) is saved with the report, shown in a DevTools-style panel, with secrets such as auth headers, cookies and passwords removed before anything is saved.

Can my AI coding assistant fix the bug?

Yes. Copy for AI turns a report into a ready prompt, and the Bug Report MCP server lets Claude, Cursor or VS Code read your team's bugs with their steps, errors and failed requests, then update the status and comment when the fix is done.

Does Bug Report work with automated tests?

Yes, with Playwright. Add @bugreport/playwright to your config in one line and you get a full test report (retries, steps, errors, trace viewer, trends, flaky tests, failures by cause), and every failed test becomes a bug report with its steps, checks, console, network and video. Create bug report puts it on your dashboard, where the developer replays it in their own browser. The reporter is free and open source (MIT).

Yes. Screenshots, step recordings, live replay, console and network capture and a team workspace for three people are free. Pro adds 30-minute videos with voice and tab sound, instant replay with video, the video timeline and trimming to MP4 or GIF.

Reports stay on your computer until you send them to your team workspace. Passwords, card numbers and one-time codes are never recorded by default, secret headers and tokens are redacted, and private details can be blurred in videos and screenshots.

← All posts

QA practice

Write bug reports developers can't argue with

October 17, 2026 · 5 min read

Every QA engineer knows the replies. Can't reproduce. Works on my machine. Which environment? Is this still happening? None of them are bad faith. They happen because a bug report is usually a description of a bug, not a definition of one. Here's how to write the second kind.

1. Say exactly what “wrong” means

“The total is wrong” starts a discussion. “The total should be 74 and shows 49” ends it. In Bug Report you add this as a check while recording: point at the element, choose what it should be (its text, a number, a value, visible or gone, a row in a table) and the report keeps both what you expected and what it showed.

A report with a check, expected and actual result and errors marked as the bug — One check and one marked request define this bug. The replay judges both.

2. Point at the error that matters

A page throws a dozen console warnings and fires a hundred requests. A developer can't tell which one you mean. Mark it: next to each failed request and console error there's The bug and Not the bug. Expected errors stop being noise, and the real one is impossible to miss.

The network panel with the failed login request's headers — The failed request with its headers, payload and response, as the developer would see it in DevTools.

3. Give the environment without being asked

Browser and version, OS, window size, screen, language and time zone are captured automatically. So are the pages you went through and the requests they made. “Works on my machine” becomes a question you can answer by comparing two lists.

4. Steps someone else can follow, or run

Good steps are short, in order, and name things the way the screen does: Click the “Sign in” button, not submit the form. Bug Report writes them from what you did, and you can reorder, edit or switch steps off. Then the developer doesn't have to follow them by hand: Replay runs them.

5. Let the replay answer “is it still broken?”

Because the bug is defined by checks and marked errors, a replay can judge it: Reproduced if anything you marked is still wrong, Not reproduced if everything checked passes, Inconclusive if it couldn't tell. Developers replay it after their fix; QA replays it before closing the ticket. Nobody has to take anyone's word for it.

A checklist to keep

A title that says what's wrong, not where: “Total shows 49 instead of 74”
At least one check with the expected value
The failing request or error marked as the bug, the expected ones as not the bug
Steps that start from a page anyone can open
Passwords and personal data left out (Bug Report hides them for you)

Start free, or read how the same idea works for automated tests.