“Cannot reproduce” is a status on a bug report. It means someone tried to make the bug happen by following the report and could not. Without a reproduction there is nothing to debug and no way to prove a fix works, so the issue often gets closed or parked with that label.
Issue trackers have long had a name for it. Bugzilla’s resolution is WORKSFORME. Jira’s default resolutions include “Cannot Reproduce.” On GitHub and GitLab it is usually a label or a closing comment. Whatever the tool calls it, it is not a verdict that the reporter was wrong. It means the report did not contain whatever made the bug happen.
The missing piece is often environment or timing. A browser version, a specific account, a large data set, a slow network, a race between two requests. Bugs that appear only under load or only sometimes are the hardest, and they tend to be closed as cannot reproduce and reopened a week later.
If you are reporting, include the steps, what you expected, what happened instead, the version or commit, the browser or OS, and any error text or logs. A screen recording settles most arguments. If you are the developer, ask for the one detail you are missing before closing, and say what you tried so the next person does not repeat it.
For intermittent bugs, add logging around the suspect path and wait. Sometimes the only reliable reproduction is production.
The shirt says “CAN’T REPRODUCE.” The bug is presumably still out there.
In the wild
Can’t reproduce on Chrome 130 or Safari 18 with a fresh account. Could you share your browser version and a screen recording?
