When a developer closes a bug as "cannot reproduce," most teams treat it as done. It isn't. It's the start of a rework loop that usually costs more than fixing the bug on the first pass.
I've sat in sprint reviews where nobody mentioned "cannot reproduce" as a theme — yet three or four tickets had bounced for weeks. The time never shows up as a single line item. It shows up as Slack threads, reopen events, and a developer sighing "I looked at this last month."
The visible cost vs what you actually pay
The visible cost is the first failed reproduction: often 15–45 minutes. Read the ticket, spin up something close to the reported environment, poke around, give up.
That number is misleading. The real cost is everything after.
1. Developer tries (and fails) to reproduce — 15–45 min
They aren't lazy. They're missing state the report never captured: which account, which filters, which API response, which path through the app. Without that, "can't repro" is the honest status.
2. QA reopens — 10–20 min
QA still sees the bug. They add more screenshots, maybe a Loom, and shove the ticket back into the queue. Now it has history — and attitude.
3. Async clarification — 1–3 calendar days
"Which tenant?" "Was the feature flag on?" "Can you share the network response?" Each reply waits on notifications and context switches. The bug sits while both people do other work. Complex cases routinely cross a sprint boundary here.
4. Second reproduction attempt — 15–45 min
Sometimes the new detail is enough. Sometimes it isn't, and you get another close. Worst case, a customer reports the same issue with an urgency tag and the original investigator has to rebuild context from scratch.
Rough math for one ticket that eventually gets fixed
| Activity | Time | Who |
|---|---|---|
| First reproduction attempt | 15–45 min | Developer |
| QA rebuttal / re-file | 10–20 min | QA |
| Clarification thread | 30–90 min spread out | Both |
| Second attempt | 15–45 min | Developer |
| Context-switch tax | ~15–25 min each | Both |
| Calendar delay | 1–3 days | Team |
Conservatively: about 90 minutes of direct work and 1–2 days of delay before anyone writes a fix.
If a team files ~20 bugs a sprint and ~17% bounce as "cannot reproduce" (a common industry ballpark), that's a handful of tickets in this loop every sprint. You're looking at several hours of direct time plus multi-day drag — on bugs that weren't fixed, just debated.
How it eats sprint velocity
These tickets don't stay neatly in the sprint they were filed. They reopen, get reassigned, and show up again two planning meetings later.
Carryover bloat. Work that should have closed in sprint N is still alive in N+2. The backlog looks bigger than the real unfinished product work because half-resolved reproductions clog it.
Context loss. The developer who poked at it three weeks ago doesn't remember the near-miss theories. The second (or third) investigation costs more than the first.
Stale retest. When a fix finally lands, QA retests in an environment that may have moved on. Setup takes longer because the original conditions are harder to reconstruct.
Why "write better reports" is the wrong mandate
Managers often respond by telling QA to be more thorough. That fails for two practical reasons.
First, the missing pieces are technical: API bodies, console stacks, exact app state. Many reporters can't collect that quickly — and even engineers skip it when filing ten bugs before lunch.
Second, handmade technical context is still incomplete. Someone pastes one error line and misses the stack. Someone copies the wrong network call.
The durable fix is capturing state at submit time: session replay, console output, and network payloads attached automatically. Then reproduction doesn't depend on heroic report writing.
Teams that make that shift usually see "cannot reproduce" nearly disappear for widget-filed bugs, far fewer follow-up questions, and faster time-to-fix because investigation starts at the failing response instead of at "please send steps again."
Four metrics worth putting on the board
- "Cannot reproduce" rate — closed-as-CNR ÷ tickets filed
- Reopen rate after a CNR close
- Time-to-close split by whether the ticket ever hit CNR
- Follow-up question rate — developer comments asking for more info
Once those numbers are visible, the cost stops feeling anecdotal. It's usually larger than people guessed, because it's spread across tiny interruptions that never make the sprint demo.
Bottom line
"Cannot reproduce" isn't a one-off failed attempt. It's a rework machine: ~90+ minutes of labor, days of delay, and velocity noise across sprints. The fix isn't longer prose in the description field. It's stopping the missing-state problem at the moment the bug is filed.