Additive Manufacturing Build Failure: What to Do Next
An Additive Manufacturing Build Failed. What Happens Next?
A build stops unexpectedly. A finished batch shows something that puts conformity in doubt. Perhaps only one part looks affected; perhaps the entire build is now suspect.
The obvious question is: what caused it?
But that is not the only question production needs to answer.
What happens to the affected parts? Should material be held? Which data needs preserving? Are downstream operations still valid? Can anything be reworked? Does the replacement build take priority over jobs already in the queue?
An additive manufacturing build failure is rarely confined to the machine where it happened. Once production is involved, the recovery can affect quality, scheduling, material, inspection, post-processing and delivery.
That is why a failed build needs more than technical troubleshooting. It needs a controlled recovery workflow.
A failed build is more than a failed print
In prototype work, a failed print may mean changing a setting and trying again.
Production is different.
One build may contain multiple parts. Those parts may already have scheduled downstream operations. The machine may be needed for another job. Material may have to be assessed before reuse. Quality teams may need evidence from the original run. A replacement build may affect customer delivery dates.
Even a seemingly straightforward decision to rebuild can therefore create a chain of operational decisions.
The technical problem may happen inside one machine. The recovery problem spreads across the workflow.
A useful recovery process should allow the team to answer three things quickly:
What has been affected?
What information do we need before anything changes?
What has to happen before production can safely move forward?
The exact answer will depend on the additive process, application, customer requirements and quality system. There is no universal disposition for every failed build. But the underlying recovery sequence can still be managed systematically.
Step 1: Stop and contain the problem
The first priority is not necessarily diagnosing the failure. It is preventing an uncertain build from progressing as though nothing happened.
That means clearly identifying the build and associated parts as failed, stopped or suspect according to the organisation's own procedures.
Depending on the circumstances, containment might include:
preventing parts from progressing to the next operation;
identifying other parts or jobs potentially affected by the same issue;
holding relevant material for assessment;
informing quality, engineering or production personnel who need to make the next decision;
recording the point at which the issue was detected.
This sounds simple. In practice, containment often exposes weaknesses in the way production information moves.
If the only indication that a build is suspect is a message in somebody's inbox or a note next to a machine, downstream teams may continue working from information that is already out of date.
A controlled workflow gives the failure a recognised status that can follow the job rather than relying on somebody remembering who needs to be told.
Step 2: Preserve the evidence before changing anything
The temptation after a failed build is to start fixing it immediately.
That can be exactly the moment useful context disappears.
Changing parameters, preparing another build or clearing machine information before recording the original conditions can make later investigation much harder.
The information worth preserving will vary by process and application, but it may include:
the build file and revision used;
machine identification;
material batch or lot information;
relevant process parameters;
machine alarms or event logs;
operator actions and recorded observations;
monitoring or sensor data where available;
photographs of the build or affected parts;
inspection results;
timestamps;
relevant maintenance or calibration information.
The goal is not to collect every piece of data simply because it exists. It is to preserve the information needed to reconstruct what happened and support an appropriate quality decision.
This matters because industrial additive manufacturing quality extends well beyond the final geometry of the part. ISO/ASTM 52920:2023, for example, addresses quality-relevant characteristics and activities across AM production processes and production sites. It does not prescribe the recovery workflow described here, but it reinforces the importance of managing quality across the wider manufacturing process rather than treating the printer as an isolated operation.
Process-monitoring data can also provide useful evidence during an investigation. Depending on the AM process and monitoring systems available, recorded process information may help teams understand the conditions associated with a suspect build.
The difficult part is often not generating data.
It is being able to connect the right data to the failed build when somebody needs it.
Step 3: Decide what has actually failed
A failed build does not automatically tell you the disposition of every part in it.
The next question is therefore not simply “Did the build fail?”
It is:
“What does this failure mean for the parts we produced?”
Depending on the process and application, the team may need to determine:
whether the entire build is affected or only particular components;
whether the issue is localised to a specific region or feature;
which specified requirements may have been affected;
whether further inspection or testing could establish conformity;
whether rework is technically and procedurally permitted;
whether the parts must be rejected.
This distinction matters particularly when several parts share the same build. Scrapping everything by default can waste usable production, while accepting parts without sufficient evidence can create a much more serious problem.
The decision has to follow the applicable drawing, specification, customer requirement, qualification route and quality procedure.
There is no universal AM checklist that can replace those requirements.
For metal powder bed fusion, ISO/ASTM 52908:2023 provides requirements relating to qualification, post-processing, inspection and testing. Its scope is specifically metal PBF, so it should not be applied as though it governs every additive process. It does, however, illustrate how acceptance decisions depend on defined quality requirements and appropriate inspection rather than the simple fact that a build completed or stopped.
Step 4: Investigate the cause without losing the production context
Once the immediate issue is contained and relevant evidence preserved, the team can investigate what happened.
An additive manufacturing build can be influenced by numerous factors, including equipment condition, material, build preparation, process parameters, environmental conditions and how the process was executed.
This article is deliberately not a troubleshooting guide. The objective is not to list every technical mechanism that can produce a defect.
The operational requirement is to make sure the investigation can connect the observed problem with the conditions under which the affected parts were produced.
That means avoiding an investigation where one team looks at machine logs, another checks material records and somebody else tries to remember which file was actually sent to production.
The context needs to stay attached to the build.
That becomes increasingly important as an operation grows. As the number of machines, operators, materials and production orders increases, reconstructing a build from memory and disconnected records becomes increasingly difficult.
Step 5: Decide whether to accept, rework, rebuild, scrap or hold
Investigation should lead to a controlled disposition.
Depending on the applicable requirements, possible outcomes might include:
Accept. Evidence demonstrates that the part still satisfies its specified requirements.
Rework. An approved operation can bring the part into conformity.
Rebuild. The part needs to be manufactured again after any required changes, reviews or actions have been completed.
Scrap. The part cannot meet the required acceptance criteria.
Hold or escalate. More information, inspection or engineering/quality review is needed before a decision can be made.
These are not interchangeable shortcuts. Nor should the decision be based purely on the cost of throwing a part away.
The appropriate disposition depends on the requirements governing that particular part and process.
For purchased AM components, ISO/ASTM 52901:2017 provides a useful example of this principle. It covers information exchanged between customer and part provider, including part definition, feedstock requirements, final part characteristics, inspection requirements and acceptance methods. The standard was reviewed and confirmed by ISO in 2023 and remains current.
The broader lesson is straightforward: acceptance is defined against requirements, not against whether a part looks usable.
Step 6: Recover the production schedule
Deciding to rebuild is not the end of the recovery process.
It creates another production problem.
The failed job has already consumed machine time. A replacement may require more material. The machine may have another build scheduled next. Heat treatment, machining, finishing or inspection slots may have been reserved around the original completion date.
Putting the replacement build at the front of the queue may fix one delivery problem while creating three others.
Production may therefore need to reconsider:
machine availability;
material availability;
replacement-build priority;
other jobs sharing the same equipment;
post-processing capacity;
inspection availability;
revised due dates;
dependencies further downstream.
This is where build-failure recovery stops looking like a printer problem and starts looking like production orchestration.
A good recovery process should make the consequences visible before somebody manually moves jobs around a spreadsheet and hopes nothing else breaks.
It should also preserve the relationship between the original build and its replacement. Otherwise, the operation may successfully remake the part while gradually losing the record of why the additional production occurred in the first place.
Step 7: Close the loop before the replacement build
One of the weakest recovery workflows is:
Build fails → change something → print again.
Even if the replacement succeeds, very little has been learned unless the change and its reasoning were recorded.
Before starting again, the team should be able to establish that the necessary action has been taken. Depending on the situation, that could include confirming that:
corrective actions have been implemented;
required reviews or approvals have taken place;
revised files or instructions are controlled;
equipment or material concerns have been addressed;
the disposition of the original parts is recorded;
the replacement job can be linked back to the original failure where appropriate.
This is the point at which traceability becomes useful for far more than an audit.
A production history should help a team understand what changed and why.
If the same problem happens six months later, the useful question is not simply whether the organisation has a record of the first failure.
It is whether somebody can find that record, understand the conditions around it and see what was done next.
What a good AM build-failure workflow looks like
The details will vary between organisations, but the operational sequence can be kept simple:
Failed or suspect build
↓
Contain the affected work
↓
Preserve relevant production evidence
↓
Assess affected parts
↓
Investigate the cause
↓
Decide the disposition: accept, rework, rebuild, scrap or hold
↓
Recover and reschedule production
↓
Implement corrective action
↓
Verify the change and close the record
This sequence is not an ISO/ASTM-prescribed build-failure procedure. It is a practical framework for organising the decisions that tend to follow a production failure.
Its value comes from making sure those decisions remain connected.
Why connected workflow data matters when a build fails
No software can guarantee that an additive build will never fail.
The more useful question is what happens to the organisation when one does.
If production status lives in one system, machine information somewhere else, material records in a spreadsheet and quality decisions in email, reconstructing a failed build can become a manual investigation before the technical investigation has even started.
It gives those decisions a clearer operational context.
Authentise FlowsAM is designed to coordinate AM jobs, machines, materials, scheduling, approvals and production records within a structured workflow. Production steps can be scheduled and tracked, where machines are connected, equipment data can form part of the wider production record..
That does not replace engineering judgement, inspection or an organisation's quality procedures.
It gives those decisions a clearer operational context.
If a build fails, the objective is not simply to record a red status against a job. It is to understand what that status affects, route the necessary actions and keep the recovery connected to the production history.
A failed build should leave the operation better informed
Build failures cannot always be eliminated. But chaotic recovery is not inevitable.
The immediate technical question will always matter: what caused the failure?
For a production operation, the equally important question is:
What needs to happen now?
Contain the problem. Preserve the evidence. Determine what has actually been affected. Make a controlled disposition. Recover the schedule. Record what changed before production starts again.
The printer may be where the failure happened.
The workflow is where the organisation recovers from it.
Next step: If failed builds still trigger spreadsheets, messages and manual replanning across your operation, explore how Authentise FlowsAM can help connect production workflows, scheduling, machine information and traceability.
