Log: Intermittent and Non-Reproducible Test Failure Investigation Register

This is a ready-to-use register for a test incident that fails once and will not reproduce on demand. Replace every <<FILL: ...>> placeholder with your own specifics, attach it to the test incident or deviation it supports, and route the periodic pattern assessment through your normal QA oversight. Verify each cited regulation against the current source before you rely on it. See Managing test failures during validation for the full disposition logic this register supports.

Why this log exists

“Could not reproduce, no further action” closes an incident on paper and leaves the actual question open: was this a transient blip, or the first sighting of a defect that only shows itself occasionally? You cannot answer that question from one attempt. You answer it by recording every attempt, across every occasion the symptom shows up, in fields structured enough to compare against each other. One unreproduced failure is weak signal. Three unreproduced failures on the same function, each logged with its own conditions, might be the same intermittent defect wearing three different dates, and the only way to see that is if someone counted.

Keep one register entry per test incident that involves a reproduction attempt. If the same symptom recurs on a different incident number, link the two incidents in Part 2 rather than starting the pattern assessment over.

Part 1: Occurrence and reproduction-attempt log (one row per attempt)

Occurrence table

Part 2: Cross-occurrence pattern assessment

Complete this section when a new occurrence is logged, and at least once before any disposition is finalized. The question here is not “did it reproduce this time,” it is “does this look like the same thing happening more than once.”

A classification of “confirmed intermittent defect” moves the item out of this register’s open-ended monitoring and into the normal deviation and corrective action path for a known defect with a low but real reproduction rate. This register is for the period before that is known, not a substitute for it once it is.

Part 3: Disposition and monitoring trigger

Acceptance criteria

• Every reproduction attempt is logged as its own row, with the conditions of that specific attempt, not summarized after the fact as “tried several times, could not reproduce.”
• A cross-occurrence pattern assessment exists before any disposition closes the item, even when the assessment concludes no pattern was found.
• A disposition resting on an unidentified root cause states the investigation performed, the risk-based justification, and a specific reopening trigger, not just “monitor going forward.”
• If the pattern assessment reclassifies the item as a confirmed intermittent defect, it is routed into the standard deviation and corrective action process and this register stops being the controlling record.

Retention

Retain this register with the linked test incident or deviation record, per the records retention schedule, for not less than <<FILL: retention period>>.

References

21 CFR 211.192 (investigation of unexplained discrepancies). EU GMP Annex 15, Qualification and Validation (2015) (documentation of deviations from the validation protocol with justification). EU GMP Annex 11, Computerised Systems (2011) (reporting and assessment of deviations arising during validation). ALCOA+ data integrity principles as described in the FDA 2018 data integrity guidance, MHRA GxP Data Integrity Guidance and Definitions, and PIC/S PI 041. ICH Q9, Quality Risk Management, for the proportionality of the monitoring and reopening decision.

Confirm the current version of each reference before issue.

Filled specimen

The following shows the register for an example intermittent failure found during OQ of a building management system monitoring a cell therapy manufacturing suite. The company, system, and numbers are illustrative.

Occurrence table

Cross-occurrence pattern assessment

Disposition and monitoring trigger

This is what the register is for: the first occurrence alone looked exactly like a fluke, and closing it there would have been defensible-sounding and wrong. The second attempt passing made it tempting to stop. The third attempt, logged with the same discipline as the first two, is what turned a coincidence into a pattern with a real electrical cause behind it.

Common inspection findings this register prevents

• A test incident closed as “could not reproduce, no further action” with no record of what was actually checked.
• Multiple unreproduced failures on related functions, logged as separate unrelated incidents, with no comparison ever made between them.
• A disposition that calls the root cause “unknown” with no risk-based justification and no condition defined for reopening the investigation.
• An intermittent defect that was in fact reproducible under the right conditions, missed because every reproduction attempt used different, undocumented conditions.
• A pattern visible in a facilities, help desk, or production log that nobody cross-checked against the validation incident.

How to adapt this register

1. Decide the trigger for opening a register entry: every test incident where the first reproduction attempt fails to confirm the original result, or only incidents already classified as GxP-relevant. State the choice in your test incident management procedure.
2. Set the minimum number of controlled reproduction attempts your procedure requires before a “root cause not identified” disposition is acceptable, scaled to the function’s risk.
3. Extend Part 2’s “similar symptom reported elsewhere” check to the specific adjacent logs your environment actually has: a help desk ticketing system, an equipment alarm history, a network monitoring tool.
4. If your quality system already has a trending or signal-detection tool that would catch this kind of cross-incident pattern automatically, reference it here rather than running the comparison by hand, and use this register to capture the individual occurrence detail that feeds it.