FRACAS: Failure Reporting, Analysis, Corrective Action

FRACAS (Failure Reporting, Analysis, and Corrective Action System) is a closed-loop process for capturing every failure, driving it to root cause, implementing a corrective action, and confirming the fix worked, then feeding what was learned back in so the same failure does not recur. It is the discipline that turns scattered failure reports into rising reliability.

The name is the method: you report failures, you analyze them, you act, and, crucially, you close the loop by verifying the action held. FRACAS came out of defense and reliability engineering, where a fielded system that keeps failing the same way is unacceptable, but the logic applies to any plant that wants its equipment and its product to get more reliable over time instead of drifting. This guide covers what FRACAS is, the phases of the loop, where it came from, and how it differs from the CAPA process you may already run.

What is FRACAS?

FRACAS is a systematic, closed-loop system for reporting, organizing, analyzing, and acting on failure data across a product or system's life. The word that matters most is closed-loop. Plenty of organizations report failures; far fewer confirm that the corrective action actually eliminated the cause and then capture that lesson so it spreads. An open loop, report a failure, fix something, move on, lets the same failure return on the next unit or the next line. A closed loop does not consider a failure resolved until there is evidence the action worked and the knowledge is recorded.

The other half of FRACAS is data. A single failure report is an anecdote; a FRACAS database of many reports is a picture. Over time it shows which failures repeat, which components dominate downtime, and whether reliability is actually improving, which is why FRACAS is the engine behind reliability growth. You cannot grow reliability you do not measure, and FRACAS is how you measure it, one closed failure at a time.

What are the phases of a FRACAS loop?

FRACAS is usually described as three named phases, failure reporting, analysis, and corrective action, wrapped in the verification and feedback that make it closed-loop. In practice the loop runs like this:

1. Report the failure. Capture it promptly and completely: what failed, when, under what conditions, what the symptoms were, and any immediate effect. A vague report cannot be analyzed, so the quality of everything downstream is set here, at the point of the failure.
2. Analyze to root cause. Investigate why the failure happened, not just what broke. Use structured root cause analysis so the finding is a real cause, not a symptom, and classify the failure so patterns can emerge across many reports.
3. Decide and implement corrective action. Choose an action that removes the cause, assign an owner and a date, and put it in place. A review board often prioritizes which failures get corrective action, because not every failure justifies the same effort.
4. Verify the fix worked. Confirm with evidence that the action eliminated the cause and did not create a new problem. This is the step that separates FRACAS from a suggestion box, a failure is not closed on the promise of a fix, only on proof it held.
5. Feed the lesson back. Record the closed failure in the database, update the design, procedure, or maintenance plan, and spread the fix to sister units and lines. This is what turns one solved failure into fewer failures everywhere.

A common enhancement is a Failure Review Board (FRB): a cross-functional group that meets regularly to review open failures, assign root-cause investigations, prioritize corrective actions, and confirm closures. The board is what keeps the loop moving instead of stalling with reports that nobody analyzes.

Where did FRACAS come from?

FRACAS grew out of reliability engineering in defense and aerospace, where a system that keeps failing in the field is a mission and safety problem, not just a cost. The U.S. Department of Defense standardized the practice in MIL-STD-2155 Failure Reporting, Analysis, and Corrective Action System, issued in 1985, which set the requirement for a closed-loop failure-management process on defense programs. The content was later carried into a handbook, MIL-HDBK-2155 as guidance. Those documents gave the method its name and its closed-loop discipline, and the same structure spread into commercial reliability and maintenance, where FRACAS now runs on everything from fleets of machines to production lines.

How is FRACAS different from CAPA?

FRACAS and CAPA overlap heavily, both are closed-loop corrective-action processes that insist on root cause and verified fixes, but they come from different worlds and emphasize different things. CAPA (corrective and preventive action) is the governing process in a quality management system, required by standards like ISO 9001 and FDA regulations, and it is oriented around nonconformities in product and quality. FRACAS is a reliability-engineering system, oriented around failures of equipment and systems over their life, and it is built to accumulate failure data for reliability growth. Put simply: CAPA lives in the quality manual and focuses on conformance; FRACAS lives in reliability engineering and focuses on failure trends and reliability metrics.

In practice the two coexist. A regulated manufacturer runs CAPA for product nonconformities and can run FRACAS for equipment and reliability, and a single serious event may appear in both. The structured, team-based methods you use inside either loop overlap too: an 8D investigation fits neatly as the analysis-and-corrective-action engine of a FRACAS entry, just as it does inside a CAPA record.

How does FRACAS drive reliability growth?

Reliability growth is the whole payoff. Each turn of the loop removes one recurring cause of failure, so if the loop actually closes, the failure rate trends down and metrics like mean time between failures trend up over time. That only works when the corrective actions are real and verified: an open loop plateaus, because the same failures keep coming back and cancel the gains. This is why a FRACAS database is worth building. Plotted over time, it shows whether reliability is genuinely improving or just churning, and it turns "we fixed a lot of things" into a curve you can defend. Formal programs track this explicitly as reliability growth tracking using the failure history to project where reliability is headed and to prove that the corrective actions are paying off.

What does a FRACAS need to actually work?

A FRACAS lives or dies on the quality and timeliness of its failure reports, and that is where most systems quietly fail. If failures are logged from memory at the end of a shift, or captured on paper that takes days to reach the person who analyzes them, the report is thin, the trend is late, and the loop drags. The whole point, timely dissemination so recurrence is prevented, depends on the failure being captured accurately at the moment it happens. FRACAS also needs the discipline to actually close: a review board or owner who confirms the fix held and records the lesson, because a database full of open reports is just a bigger anecdote.

This is where a connected floor changes the economics. When failures are captured live at the point of work, tied to the machine, the line, and the conditions, the report is complete before anyone reconstructs it, the failure database is accurate instead of remembered, and repeating fault signatures surface early enough to act on. That live capture is what Harmony gives a plant, working alongside your existing maintenance and quality systems with no rip-and-replace. The processor in our CLS case study moved from failure data found the next morning to failure data visible during the shift, which is exactly the condition a closed-loop system needs to close quickly. Feed that clean failure data into the loop and it does the one thing FRACAS exists to do, drive FMEA risk down and reliability up over time. See how the capture works on the features overview.