When to Take Action on Field Failure Data?

Last Verified July 10, 2026

Why a Reactive Approach to Field Failures Falls Short

Not much. You need just enough field failure data to identify the root cause and determine if and how to resolve the problem.

Field data will accumulate even if your program works diligently to prevent failures.

The actions taken before the reported failure will frame when you need to take action.

Gathering failure data and evaluating the trigger points for action is a reactive approach. This approach means you will only respond to problems.

You will also likely not spot the important emerging issues before they become significant problems.

The meaning of field failures

A failure in your customer’s hands is your product not meeting your customer’s expectations.

Not all field failures result in a call, return, or complaint. Therefore, the failures that you do learn about become critical sources of information about how well your product is or is not meeting expectations.

Let the Customer Define What Counts as a Field Failure

You do not have to reproduce the failure, nor confirm it was due to negligence or abusive use to reclassify the failure to something else.

Field Failures Extend Beyond Hardware and Software

A failure in your customer’s eyes is not limited to hardware or software elements of the system.

I once received a product return because the box said it was 100 meters in length, and it was closer to 103 meters. The length should match the labeled length, it is a failure according to this customer.

A failure could be a problem with the advertising, ordering process, or assembly instructions.

A failure that is hardware or software related may be harder to remedy, yet any failure is a symptom of a process failure in your organization.

Every failure contains information

A failure provides an immense amount of information if you look. Each failure may include:

Symptoms noticed by the customer (what they deem a failure)
Environment and use conditions surrounding the product
Functional and duration expectations
Consequences of failure (safety, collateral damage, loss of function, etc.)
Time of failure (along with the manufacturer or installation date)
Root cause of failure
Condition of elements that have not failed
And, more

Beyond tracking time on customer service calls or cost of repairs, track the essential information you need to understand the how, why, and when of each failure.

Finally, this information is valuable, so make it easy for your customers and your organization to gather and report.

It is important to remedy the issue quickly with your customer. It is vital you have the information to resolve the current problem and prevent future issues.

Economics of root cause analysis

Not addressing a field failure not only allows ongoing warranty claims, but it also erodes your brand loyalty and market share.

Not addressing the right true cause(s) of a failure wastes design and operations resources that may exacerbate the actual problem.

Using the component switch and check approach may help find the damaged component. It may or may not lead to the root cause of the failure. Components can fail as they are the hero or victim of a fault elsewhere in the product.

Sending the identified part to a vendor may lead to a prompt and efficient solution. It also may lead to an extended time of little information and no resolution. Instead, use an internal or contracted failure analysis laboratory.

Sure, it will cost a bit, yet in short order, you will have a clearer root cause understanding, and then you can move to effectively solve the problem.

Class Defect Versus Isolated Anomaly

When faced with a unique field failure, or even just the first (or only) reported issue, do you spring to action with a full root cause analysis and line stoppage till it is sorted out?

Most of you would not do this for a single reported failure.

If the failure caused a death, you would immediately investigate in detail. Hopefully, this is a very rare event with your product.

If the failure was from an important customer and they demanded an investigation, you would start immediately.

Addressing the problem may be a business decision and not motivated by a desire to improve your product.

Once you have compelling information that a significant portion of fielded products will fail, or you experience an increased rate of returns, you likely will take action. This may be too little information too late to thwart the impact of the class defect. Part of acting early is deciding when field data warrants accelerated testing to surface latent failures before they compound.

Build Your Field Failure Response Before First Product Ships

During the design and development, you identify reliability risks, you find and resolve problems, and you also identify and do not solve problems.

The issues you resolved provide a database of failures that you know fairly well, and if they appear even once in field failure data, that should be a surprise requirement for corrective action. Just one failure of a known “solved” issue is a cause for alarm.

Think about it, you identified an issue and chose to spend resources to solve the issue.

The failure provides evidence that the issue was not solved. Something went wrong, and the risks to product performance, warranty costs, etc., are all back on the table.

When Mitigation Is the Only Option for Recurring Failures

Did the failure arrive as expected after the expected duration, given the conditions? If it is early — again, even just one failure — means something went wrong with the process to solve the problem.

Finally, some problems have not been seen before. Customers are creative that way.

Given the work to understand and solve as many issues during the development phases, a new type of failure will require root cause analysis. Even on just the first one reported.

You may decide not to resolve the issue with a design or process change, as you determine the failure will be an infrequent source of failures.

Do not base your actions on opinion, but rather on the root cause analysis and good reliability engineering work.

How much failure data do you need?

Just one field failure is all you need to take action. You should take action given just one field failure.

Waiting to confirm that cracked capacitors due to board bending will cause 5% or more units to fail, may require you to wait till 5% or more fail. Instead, with the first cracked capacitor, you can identify the source of the board’s bending and stop it.

Immediately reduce the chance of capacitors cracking.

You still need to deal with the existing products that are at risk of failure.

If the root cause is not identified and solved early, you continue to produce systems with some fraction including defects, leading to failure. Working to solve the root cause of the initial failure may lead to short and long-term improvements to your process to create reliable products.

Take Action on Field Failure Data: Key Takeaways

How do you know when to take action? Add a comment and share your best practices.