What is FRACAS in maintenance and reliability?
FRACAS stands for Failure Reporting, Analysis, and Corrective Action System. It is a closed-loop reliability process that captures failure events and relevant context, screens them for significance and recurrence, analyzes causes at the depth warranted by risk and uncertainty, assigns corrective actions, tracks implementation, verifies whether those actions changed the failure behavior, and preserves lessons so the same defect is less likely to recur elsewhere.
Capture the event with enough identity and context to support later analysis.
At minimum, preserve the asset or function, date and operating state, observed symptom, functional consequence, relevant failure code or description, maintenance response, downtime or labor where reliable, and links to the work order or other evidence.
Do not wait for a perfect taxonomy before capturing useful facts. Stable asset identity and good event narrative are often more valuable than a long code list used inconsistently.
Not every failure deserves the same analysis depth.
Use consequence, recurrence, uncertainty, safety or quality relevance, cost, downtime, mission impact, and prior corrective history to decide the response. Some failures can close with normal corrective work. Others should trigger repeat-failure review, focused engineering analysis, or formal RCA.
The screening rule should protect high-consequence events even when frequency is low.
Link the event to a defensible failure explanation.
Analysis can range from technician confirmation of a known failure mechanism to formal multi-disciplinary RCA. Preserve the distinction between observed failure mode, suspected cause, confirmed cause, and unresolved uncertainty.
Where a failure pattern repeats across similar assets, FRACAS should make that pattern visible so corrective action can scale beyond one work order.
Corrective action needs ownership, authority, and verification.
Assign an owner, action, due or review date, technical authority where needed, implementation evidence, and effectiveness measure. Closing the action because a part was installed is not the same as verifying the failure mechanism is controlled.
For design, safety, quality, OEM, or regulatory changes, use the required approval process. FRACAS should track the controlled decision, not bypass it.
The system should reduce future investigation effort by preserving what was learned.
Feed verified failure modes, causal findings, corrective actions, parts changes, PM strategy changes, job-plan improvements, and design lessons back into the CMMS, asset strategy, standards, or equipment knowledge system used by the plant.
A mature FRACAS process can answer not only what failed this month, but which prior corrective actions are still open, which failures are recurring, and whether implemented actions actually changed the trend.
What makes FRACAS different from a failure database?
Closure. The system connects failure reporting to significance screening, analysis, corrective action, implementation evidence, effectiveness verification, and reusable learning rather than stopping at event capture.
- Preserve stable asset and event identity.
- Scale investigation depth to consequence and uncertainty.
- Track corrective actions to implementation and verification.
- Use recurrence to test whether closure was real.
Technical references
- NASA Reliability-Centered Maintenance Guide — Discusses recurrence control, root-cause failure analysis, and reliability improvement feedback.
- ISO 14224:2016 — Provides a current framework for standardized equipment, failure, and maintenance data.
Close the loop between failure history and reliability improvement.
Use FRACAS to make every significant failure traceable from event evidence through corrective action and later effectiveness verification.
Bad Actor Analysis See facility-specific XRVE services