Cannot Reproduce a Bug? What to Check Before Closing the Report
A failed reproduction is a clue about the test conditions, not proof the user imagined a problem. Compare builds, roles, devices and data, then ask for one precise missing detail.
5 min read
"Cannot reproduce" means the investigator did not see the reported behavior under the conditions they tried. It does not prove the report is false. A different build, account role, device, data state or timing can change the result. Before closing the report, record exactly what was tested and identify the smallest missing condition that might explain the difference.
Compare the environments before repeating the clicks
- Build and deployment: Which app version, release channel and backend were involved? A fix may exist in one environment but not another.
- Identity and permissions: Was the reporter a customer, admin or member with a different role? Use a safe test identity with equivalent access; do not ask for their password.
- Device and browser: Note operating system, browser or app version, screen size and relevant settings when the symptom depends on them.
- Data and timing: Was the account new, the record already edited, the request retried, or another action happening at the same time?
- Network and error evidence: A timeout, failed request or server trace can explain a symptom that a clean local run never shows. Handle logs according to the project privacy rules.
The Bugzilla guidance on writing bug reports (opens in a new tab) stresses clear steps, actual and expected results, and environment detail. Those fields also guide the investigation after the first attempt fails. The bug-report guide covers how to make the initial report; this article starts when someone has already tried it and got a different result.
Change one condition at a time
Start with the reporter's exact path and the closest safe copy of their conditions. Then vary one plausible factor: for example, use the same build with a different role, or the same role with a fresh record. If several things change at once, a successful reproduction will not tell you which condition mattered. A screen recording can show the path, but it may hide network failures or account state; treat it as one piece of evidence.
Ask a question the reporter can answer
Instead of "Can you send more information?", say what you did and ask for the missing discriminator: "I tried version 2.4 on Android with a newly created record and did not see the error. Did your record already have an attachment when you tapped Save?" A support agent can ask the same question without asking the customer to reproduce a risky payment or destructive action.
Record the negative result accurately
Leave the report with a concise investigation note: tested version, environment, role, sample data, exact steps, observed result and evidence checked. State the conditions you could not match. If the impact is serious, do not close solely because the clean environment worked; use logs, monitoring and an owner-led decision about next steps. If the issue is low impact and evidence cannot be obtained, triage may defer or close it with a clear reason and a route to reopen when new evidence appears.
The bug life-cycle guide covers who changes states and when a closed issue is reopened. Here the goal is narrower: make "cannot reproduce" a documented investigation result rather than an unexplained dismissal. Fenbs can hold the report, follow-up question and evidence in one task; it does not automatically reproduce bugs.