We cannot reproduce a reported defect. Should we close it?
Insufficient defect evidenceKeep the report in a clear investigation state while gathering context proportionate to impact. Failure to reproduce once is not proof that the user's experience did not occur.
What to do now
- Collect environment and timing details
- Request safe representative evidence
- Test plausible conditions
- Agree a monitoring or closure decision with rationale
When to escalate
Escalate when
The reported impact is severe despite limited reproducibility.
Who decides
The acceptance authority and relevant quality owner
Example
An intermittent timeout is investigated using timestamps and workload conditions rather than dismissed.
Mistake to avoid
Closing a serious report solely because it works on one developer's machine.
Prevent a repeat
Check that closure evidence proves the agreed outcome instead of relying only on a completion percentage.
Suggested ApprovedFlow setup
- Tasks
- Documents
- Approvals
Attach acceptance criteria and test evidence to the deliverable or task, then record the authorized review decision. See the platform
Related cases
- A defect fix breaks another feature. How can we prevent this?Insufficient regression protection
- We have many defects but no severity agreement. How do we prioritize?Inconsistent defect severity
- Audit asks for evidence, but the team only has verbal assurances. What can we provide?Insufficient control evidence
- The customer verbally accepts delivery but will not sign. How should I close?Ambiguous acceptance evidence