What Should Happen in Your MES When an AM Build Fails?
An AM build fails six hours into a 14-hour run.
The printer knows it failed. But what happens to the parts on the plate? What happens to the powder already used, tomorrow's machine schedule, the heat-treatment slot booked for those parts and the production record that now needs explaining?
Recording “Build failed” is the easy bit.
The more important question is what happens next.
A failed additive manufacturing build creates work across production, quality, materials and planning. A capable manufacturing execution system (MES) should help control that response, preserving what happened while making sure affected work does not quietly continue through production as though nothing changed.
The failure should not end the workflow. It should start a different one.
A Failed Build Creates More Than a Machine Problem
It is tempting to treat a build failure as a printer event.
Machine stops. Operator records the failure. Job gets rescheduled.
In production, the consequences are wider.
Imagine a laser powder bed fusion build containing eight customer parts. A recoater problem stops the build halfway through. Production now has several questions to answer.
Are all eight parts scrap? Is any material recoverable? Does the machine need inspection before another build starts? Should the replacement parts return to the front of the queue? Do downstream operations need cancelling or moving? Does quality need to investigate before another attempt is allowed?
Those decisions affect different parts of the manufacturing workflow, but they all originate from the same event.
That is why failure handling belongs inside the production workflow rather than in a separate spreadsheet, email chain or operator notebook.
First: Stop the Failed Build Moving Through Production
The first responsibility is containment.
Once a build has failed, affected parts should not continue automatically to post-processing, inspection or delivery simply because the next operation was already scheduled.
The system needs a clear status indicating that something has changed and that further action is required.
What happens next will depend on the organisation's procedures. One manufacturer might require an engineering review. Another may route the job directly to quality. A relatively routine failure may allow an authorised production lead to decide whether to reprint.
The important point is that the production system should recognise the exception.
A workflow that works perfectly while everything goes to plan but relies on emails as soon as something goes wrong is only partially digital.
Preserve the Failed Build Record
The failed attempt should remain part of the manufacturing history.
That sounds obvious, but poorly controlled rework processes can make production history surprisingly difficult to follow.
Suppose the original build fails, a second build succeeds and the order is eventually completed. Looking only at the final successful part should not make the first attempt disappear.
The production record should retain information such as the build identity, timing, machine, material, relevant process data, operator activity and recorded observations. Where required, it should also show what decision followed the failure and who made it.
This matters for more than compliance.
When the same problem appears three months later, engineers need to know whether they are looking at a new issue or repeating something that has already happened.
Preserving production data also matters beyond the immediate investigation. ISO/ASTM 52953:2025, for example, defines minimum requirements for registering process-monitoring and quality-control data for metallic parts produced using laser-based powder bed fusion. Although its formal scope is specific to that process, the standard notes that the procedures can also be applied to monitoring other AM processes and materials.
Decide What Actually Failed
A failed build does not always mean every part on the build has the same outcome.
This becomes particularly important with nested production.
Perhaps one part detached from the plate and caused the machine to stop. Perhaps an anomaly was detected in one region of the build. Perhaps the process stopped early enough that everything must be rejected.
The manufacturing workflow should support the organisation's disposition process rather than assuming every failed build has the same outcome.
That might mean separating affected parts into statuses such as hold, review, scrap, rework or reprint. The terminology and decision authority will vary by organisation and regulatory environment.
What matters is maintaining the relationship between the build-level event and the part-level outcomes.
Otherwise, useful detail gets flattened into a single status: failed.
That loses information the moment it is needed most.
Update Material, Machine and Quality Status
The parts are not the only things affected.
For powder-based processes, the failure may change the status or history of material associated with the build. Material consumption still happened even if no usable parts came out of the machine. Depending on the process and the cause of failure, recovered material may also need additional controls before reuse.
The machine may need attention too.
A software interruption and a damaged recoater blade do not have the same implications for the next production order. If maintenance, inspection or operator intervention is required, the machine's availability should reflect that rather than remaining theoretically free in the production schedule.
Quality may also need to become part of the workflow. A build that reaches the end of printing can still fail later during dimensional inspection, CT, mechanical testing or another quality gate.
NIST's work on AM process monitoring highlights the relationship between process signatures, defects and final part quality, while ASTM guidance on in-process monitoring similarly distinguishes detecting process anomalies from deciding what they mean for the finished component.
Detection provides evidence.
It does not automatically provide disposition.
Recalculate the Production Schedule
A failed 14-hour build does not merely consume 14 hours.
It can move everything behind it.
The replacement build may need another machine slot. Post-processing reservations may now be wrong. Inspection capacity may have been allocated to parts that will not arrive. Another customer order may need moving.
This is why additive manufacturing scheduling cannot operate independently from execution.
A useful MES should expose the changed production reality so a planner can respond to it.
That does not mean handing every scheduling decision to an algorithm. In complex or regulated manufacturing, people still need to judge priorities and consequences.
The value comes from replanning with the right information.
If the schedule still assumes the failed build will reach heat treatment tomorrow morning, it is no longer a schedule. It is an outdated plan.
Create the Reprint or Rework Without Losing the Link to the Original
Once the disposition is clear, production may need to create replacement work.
This is another point where traceability can break.
A reprint should not become an entirely unrelated new order that happens to contain the same geometry. The relationship between the failed attempt, the decision to manufacture again and the successful replacement is valuable manufacturing information.
The same applies to rework.
If a part fails inspection, goes through an approved corrective operation and later passes, the final status should not erase the fact that rework occurred.
For regulated or high-reliability manufacturing, that history may become particularly important during investigation, qualification or audit.
👉 Traceability & Compliance in Additive Manufacturing: The Complete Guide
The aim is not to produce a bigger pile of records.
It is to preserve a coherent manufacturing story.
Capture Enough Context to Understand Why the Build Failed
A machine alarm can tell you what the equipment detected.
It may not tell you why the problem happened.
Consider a build record that says:
Build stopped at 14:32 – recoater error.
Useful? Yes.
Enough to prevent the same problem happening again? Probably not.
The useful context may include an operator noting unusual powder behaviour, a material batch change, recent machine maintenance, a modified parameter set or an engineering decision made before production began.
This is why contextual manufacturing data matters.
Two organisations can collect identical machine data and learn very different amounts from it. The organisation that can connect a failed build to the material, process, operator observations and earlier decisions has much more useful evidence than the organisation with a timestamp and an error code.
A Failed Build Should Improve the Next One
Failure data becomes more valuable when it can be examined across builds.
One recoater failure may be an isolated event.
Five failures involving the same machine, material batch, parameter set or part family deserve attention.
A good manufacturing record makes those patterns easier to find.
Teams can begin asking better questions:
Is first-pass yield deteriorating on a particular machine?
Are similar defects appearing with one material batch?
Does a particular geometry repeatedly require rework?
Are failures increasing after a maintenance interval?
Are certain process deviations associated with later inspection problems?
This is where failure handling stops being an administrative exercise and becomes useful production knowledge.
The objective is not simply to document why yesterday's build failed. It is to make tomorrow's decision better.
What Good MES Failure Handling Looks Like
There is a simple test.
If a build fails and somebody immediately has to open a spreadsheet, message three people and manually work out what needs changing, the failure workflow is not really being managed by the MES.
Good failure handling does not mean removing human judgement. Quite the opposite. Quality, engineering and production teams often need to make decisions that software should not make on their behalf.
The system's role is to give those people a controlled place to make the decision and preserve what happened afterwards.
In practice, that means the manufacturing workflow should be able to:
retain the original failed-build record;
prevent affected work progressing unchecked;
connect build failures to affected parts;
record observations, decisions and disposition;
preserve relevant material and process history;
reflect changes to machine availability;
support replanning and replacement production;
maintain the relationship between the original build and any rework or reprint.
Authentise FlowsAM approaches this as a manufacturing execution problem rather than simply a machine-monitoring problem. It combines production planning and scheduling with machine-status visibility, production history, quality capture and traceability.
Flows also supports production changes after manufacturing has begun. Depending on the situation, users can change the remaining workflow, remanufacture one or more pieces, send pieces through a non-conformance review or record them as scrap. This allows the production response to remain connected to the manufacturing record rather than being managed separately through spreadsheets or email.
That distinction is important.
The goal is not software that makes every quality or production decision automatically. It is a production system that gives teams the information and workflow controls they need to manage exceptions without losing the history of what happened.
The Failure Is Part of the Process
Nobody wants an AM build to fail.
But production systems should be designed on the assumption that occasionally one will.
Machines stop. Parts fail inspection. Materials behave unexpectedly. Process deviations happen. Priorities change.
The test of an additive MES is therefore not simply how neatly it tracks successful work.
It is how well it manages reality when production deviates from the plan.
A failed build should leave production with more than a red status icon. Teams should know what is affected, what needs deciding, what happens next and where the evidence lives.
Because a build failure should not break the digital workflow.
It should trigger the workflow designed to deal with it.
If failed builds still send your team into spreadsheets, email threads and manual replanning, explore how Authentise FlowsAM connects production status, scheduling, quality and traceability within the additive manufacturing workflow.
Comments