A Playbook for Killing Cannot-Reproduce Bug Tickets

Every backlog has them: tickets closed with a shrug and the words cannot reproduce. The reporter swears it happened. The developer ran the steps and got nothing. Both are telling the truth, and that is the whole problem. A bug report written as prose records what the user did, but a failure depends on the state the user was in — the viewport, the account, the feature flag, the exact API response. When that state is missing, the same click sequence passes on the developer's machine and the ticket dies as noise.

This is not a motivation problem you fix with a sternly worded template. It is a structural mismatch in what reports carry versus what reproduction needs. Below is a playbook that treats the cannot-reproduce ticket as a measurable defect in your intake pipeline and drives its rate toward zero with four concrete moves.

The evidence that this is structural rather than careless is decades old. Bettenburg and colleagues surveyed developers and reporters across Apache, Eclipse, and Mozilla and analyzed 466 responses. Their core finding: steps to reproduce, stack traces, and test cases are simultaneously the items developers rate most useful and the items reporters find hardest to provide. The most valuable signal is the scarcest signal. That gap is where cannot-reproduce tickets are born.

The cost is quantified too. The Works for me! empirical study of Firefox and Eclipse found that non-reproducible reports make up roughly 17% of all bug reports and stay active about three months longer than reproducible ones. They are not a rounding error. They are one ticket in six, sitting open far longer, consuming triage cycles that produce nothing.

The single highest-leverage move is to stop asking humans to transcribe what happened and record it instead. An rrweb-style recorder captures a full DOM snapshot plus every incremental mutation, mouse and scroll input, viewport and window resize, console output, and network activity — and reconstructs the session without a video file. That last detail matters: it is structured data, not pixels, so it is searchable, lightweight, and replayable at the DOM level.

This is the mechanism behind the claim that a replay carries the missing precondition. The viewport width that broke the layout lives in the resize events. The empty cart that produced a blank checkout page lives in the captured POST response. The console error that fired two seconds before the click is sitting on the timeline. The developer does not re-derive the triggering state from a paragraph — they read it back from the recording.

Replays carry interaction state; an explicit environment block carries the platform facts a triager would otherwise have to extract by hand. Stamp these onto every report automatically. The point of automating them is precisely that a human omits whatever feels obvious in the moment, and obvious is usually the precondition.

Viewport dimensions belong in CSS pixels with device pixel ratio, because a layout bug that only appears at 1280×720 on a 2× display is invisible to a developer sitting at 1920×1080. The build SHA tells you whether the reporter even saw the code you are debugging. None of this is typed by a human.

Mozilla's Bug Writing Guidelines are blunt: steps to reproduce are the most important part of any bug report, and if the steps are unclear it might not even be possible to know whether the bug has been fixed. The guidelines stress minimizing steps and stating expected versus actual behavior. Standardization is how you enforce that without nagging.

Crucially, standardizing does not mean a longer form. The heavy artifacts — replay, console, network, environment — are captured automatically. The human writes only the irreducible narrative core. Copy this template into your issue tracker and let automation fill the bracketed slots:

What you do not measure, you cannot drive down. Define the KPI precisely: the count of bugs closed as cannot reproduce, works for me, or needs more info, divided by all bugs closed in a fixed window. Track it per team and per report source. A triager closing a ticket as non-reproducible is signalling a defect in intake quality, so segmenting by source tells you which capture path is leaking state.

Baseline the rate before you change anything. Then watch it fall as Steps 1 through 3 land. The number is a direct proxy for wasted triage cycles, and because the Works for me! data shows these tickets stay open about three months longer, a falling rate also shortens your tail of stale bugs.

The data-fusion follow-up study (ICSME 2020) examined 576 non-reproducible reports from Firefox and Eclipse and identified 11 distinct factors that push a report to non-reproducibility, including missing information, environment differences, and ambiguous expected behavior. The reason a captured bundle works is that you can trace each cause to a specific artifact that eliminates it.

Missing information is killed by the console and network capture. Environment differences are killed by the environment block. Viewport-specific failures are killed by the recorded resize events. Ambiguous expected behavior is killed by the standardized expected-versus-actual field. The bundle is not one fix — it is four overlapping fixes aimed at the four most common causes.

The comparison is deliberately two-sided. A plain tracker wins on footprint: it is already in your stack and needs nothing installed, and it works for a reporter who will not add an extension. Capture-first reporting trades that friction for state. The row that decides it for AI workflows is the MCP one — an agent reading a structured bundle behaves differently from an agent parsing a paragraph.

An AI coding agent hits the exact failure mode that traps human triagers: given only prose steps, it must guess the triggering conditions. Bundle the replay, the console, the failing request, and the environment, and reproduction becomes a deterministic read. BugMojo exposes that bundle to agents like Claude Code and Cursor over an MCP server, so an agent can pull the failing request and the viewport state alongside the steps, form a hypothesis, and write a failing test before it patches anything. A plain text field cannot offer that, because there is nothing structured to read.

For the structural detail on why written steps degrade, see the companion glossary entry on reproduction steps — it covers the same reporter/developer information mismatch from the artifact side rather than the measurement side.