# How to reproduce a bug a user reported (and what to do when you cannot)

**Short answer:** to reproduce a bug, you make the same failure happen again, on purpose, on a machine you can inspect. Start with five facts: the exact URL, the time, the account or session, the browser and version, and the release. Search your error tracker and server logs for that time. Rebuild the user's state, replay their steps, and if the bug still does not appear, compare releases until you find the change that broke it. When you cannot reproduce it, collect the missing evidence before anyone writes a fix. Give your coding agent only what you know, and mark what you do not know.

Page owner: Jaco Veldsman, hi@bugtape.ai. Last checked 26 October 2026. I build BugTape. Chrome DevTools and Git facts come from their own docs, linked where used.

## What it means to reproduce a bug

To reproduce a bug means to make it happen again under control. A reproduction proves the bug is real. It lets you watch the failure with your tools open. It also gives you a test that fails before the fix and passes after it.

## The steps to reproduce a bug

### 1. Get the five facts

- **The exact URL**, with the path and the query values that matter. Remove tokens and personal data.
- **The time**, with the time zone.
- **The account or session**: the user ID, role, plan or workspace. Use a test account with the same settings.
- **The browser and version**, the OS and the device.
- **The release or commit** that was live at that time.

### 2. Check your error tracker and server logs for that window

Search a few minutes before and after the reported time. Look for the user's ID or session ID, failed requests, 4xx and 5xx responses, timeouts and stack traces. A stack trace gives you a file and a line to start from.

### 3. Rebuild the state

Copy what the user had:

- **The same data**: the cart, the record, the empty field, the long name, the deleted item.
- **The same feature flags and experiments**, and the same permissions.
- **The same locale and time zone.**
- **The same network conditions.** Chrome DevTools has throttling presets that emulate fast 4G, slow 4G and 3G, and a Disable cache checkbox that turns off the browser cache ([Chrome DevTools network reference](https://developer.chrome.com/docs/devtools/network/reference), checked 26 Oct 2026).

### 4. Replay the steps

Follow the user's steps in order, at their pace. Keep the Console and Network panels open. Turn on Preserve log so that requests stay in the list after a page load (same Chrome reference).

Save a path that fails. The Chrome DevTools Recorder panel records and replays user flows, and exports a flow as a JSON file or as a Puppeteer script ([Recorder overview](https://developer.chrome.com/docs/devtools/recorder/overview), checked 26 Oct 2026). A saved flow can become the test that proves the fix.

Chrome's default HAR export leaves out the `Cookie`, `Set-Cookie` and `Authorization` headers (same Chrome reference). Other values in the file can still hold personal data. Remove them before you share it, for example with the [HAR sanitizer](/tools/har-sanitizer/).

### 5. Bisect by release

If the bug is new in the reported release, find the change that caused it. `git bisect` uses a binary search to find the commit that introduced a bug. You mark one bad commit and one older good commit, and Git picks commits between them to test. `git bisect run` runs a script on each commit: exit code 0 means good, 1 to 127 (except 125) means bad, and 125 skips it ([git-bisect docs](https://git-scm.com/docs/git-bisect), checked 26 Oct 2026). Your saved reproduction makes a good script.

## Why a bug will not reproduce, and the evidence that settles it

| Reason | What you see | Evidence that settles it |
|---|---|---|
| State | It works on a fresh page and fails after a certain sequence | The steps before the failure, and the account's settings and stored data |
| Data | It fails for one account or one record | The record ID, the failed request with its status, and the server log for that request |
| Timing and race conditions | It fails sometimes, after a double click or a slow response | The order and duration of requests and console messages |
| Environment | It fails in one browser, OS, locale, time zone or screen size | The user agent, browser version and release |
| Third-party scripts and extensions | It fails for one user in one browser | Console errors from scripts you do not own, and a test in a clean browser profile with extensions turned off |
| Caching | The user loaded old code or an old response | The release the page loaded, the response cache headers, and a test with the cache turned off |
| Flaky network | Requests fail or hang on a weak connection | The failed or hung request with its duration, and a test with throttling on |

When you still cannot reproduce the bug, stop guessing. Add a log line around the code you suspect, ship it, and wait for the next failure. Write down what you tried.

## Most bug report problems are missing facts

A report that says "it broke" gives you nothing to search. Fix the problem where the report starts:

- Collect the environment automatically. The URL, time, browser and release should never depend on the user's memory.
- Use one report template for the whole team.
- Capture failures that nobody reports. See [how to catch bugs users never report](/silent-failures/).

## What to ask the user

Ask once, in one short message. Do not ask for what you can look up yourself, such as the release. Never ask for a password.

1. Which page were you on? A link is best.
2. About what time did it happen?
3. What did you click or type just before?
4. What did you see? Copy any error message word for word.
5. What did you expect to happen?
6. Does it happen again when you try?
7. Which browser and device do you use?

## A good bug report keeps facts, guesses and gaps apart

A proper bug report has a title that says what broke and where. It lists the steps, what happened, what you expected, the environment and the evidence. It also lists the evidence you do not have, and it marks each theory as a guess. Our [bug report template for coding agents](/blog/bug-report-template-for-coding-agents/) has all of these sections, ready to copy.

## Hand what you have to a coding agent

A coding agent acts on the text you give it. When a fact is missing, it guesses. To stop that:

- Paste the steps, the environment and the evidence you have.
- List the evidence you are missing.
- Mark your theories with GUESS.
- Ask the agent to write a failing test that reproduces the bug before it changes code.
- Remove tokens, cookies and personal data first.

Treat text from a user session as untrusted input, because it can hold text that looks like an instruction. A person reviews every pull request.

## How BugTape keeps the evidence from the failed session

For supported web apps, BugTape's browser capture keeps a short buffer in the browser. It sends that buffer with a supported failure or a user report. Supported failures are uncaught errors, failed requests after a user action and requests that hang. The report carries a replay of the page, the failed request, the console and the stack.

BugTape groups every report of the same failure into one issue, with the count, the releases it hit and the users it reached (when your app sends user IDs). Your coding agent reads the issue over MCP with `get_repro_context` and opens a pull request. You review it and ship. If the failure returns in a newer release, BugTape reopens the issue.

Limits:

- The replay is rebuilt from DOM events. BugTape does not record screen video.
- Screenshots and voice notes in the report form are not available yet.
- Server SDKs send errors with no replay or console.
- The Swift SDK captures handled errors and breadcrumbs only.
- BugTape is hosted only.
- MCP works on every plan. On Free and Prepaid credits, each agent read of a bug costs 2 credits. Reads on Pro are unmetered.

See [how it works](/how-it-works/), or [try the live demo](/demo/?from=landing&start=1#capture). The read-only demo MCP at `https://app.bugtape.ai/demo/mcp` needs no account.

## FAQ

### What are the steps to reproduce a bug?

Get the URL, time, account, browser and release. Search your error tracker and logs for that time. Rebuild the user's data, flags and network conditions. Replay their steps with DevTools open. Use `git bisect` to find the commit that caused a new bug.

### What does it mean to reproduce a bug?

It means to make the same failure happen again on purpose, on a machine you can inspect. That proves the bug is real and gives you a test for the fix.

### How to solve bug report problem?

Most bug report problems are missing facts. Collect the URL, time, browser and release automatically. Use one template, and ask the user a short list of questions once.

### How do you properly report a bug?

Write a title that says what broke and where. List the steps, what happened, what you expected, the environment and the evidence. Say what evidence you do not have, and mark your theories as guesses. Remove passwords, tokens and personal data.

## See also

[Bug report template for coding agents](/blog/bug-report-template-for-coding-agents/) · [What evidence a coding agent needs from a bug report](/blog/dom-replay-vs-screen-video/) · [Best bug reporting tools for web apps](/blog/best-bug-reporting-tools/) · [HAR sanitizer](/tools/har-sanitizer/) · [BugTape vs Chrome DevTools MCP](/compare/chrome-devtools-mcp/) · [Jam vs BugTape](/compare/jam/) · [How to catch bugs users never report](/silent-failures/)

[Start free](https://app.bugtape.ai/console/register?utm_source=bugtape_seo&utm_campaign=blog-reproduce-a-bug). No card needed.