Corrective Maintenance: A Complete Guide

Ask ten maintenance people to define corrective maintenance and you will get two answers. Roughly half will say it is the work you do when something breaks. The other half, usually the ones who have read a terminology standard at some point, will say it is the work you do once a fault has been detected, which is a very different and much wider thing. The second group is right, and the gap between the two answers explains an enormous amount of confusion in work order data, in KPI reporting and in the arguments that break out during a weekly planning meeting. This guide takes corrective maintenance seriously as a work category with its own lifecycle, its own decision points and its own failure modes as a process.

The message up front: a fault detected is not the same as a failure occurred. Corrective maintenance is triggered by fault detection, not by stoppage, so a great deal of corrective work is done on assets that are still running. The single most valuable skill in managing this category is deciding honestly which corrective jobs must be done immediately and which can be safely deferred, and then recording that decision so well that anyone reviewing it six months later can see it was sound.

1. What corrective maintenance actually is

The clean definition, and the one that European maintenance terminology has settled on, is that corrective maintenance is the maintenance carried out after a fault has been detected, in order to restore an item to a state in which it can perform its required function. The controlling word is fault, not failure, and the controlling phrase is required function, not "working" in some loose everyday sense.

That has two consequences that most sites get wrong. First, corrective maintenance is not defined by an asset having stopped. It is defined by someone having found something wrong. Second, "restore to a state in which it can perform its required function" means the target is the function, not the appearance of the machine. A chiller that still produces cooling but has lost one of two compressors is no longer performing its required function if that function was specified with redundancy. It has not broken down. It very much needs corrective work.

So the honest scope of corrective maintenance includes all of the following:

• Work on a stopped asset. The obvious case, and the one everybody already counts.
• Work on a degraded but functioning asset. A pump running with a weeping gland, a fan with a noisy bearing, a door closer that still closes but slams. The function is impaired or at risk, not absent.
• Work on a failed redundant component. The duty and standby pair where the standby has failed. Nothing has stopped. A protective layer has gone.
• Work arising from inspection findings. A preventive inspection finds a cracked bracket. The inspection is preventive. The bracket repair that follows is corrective. This is one of the most commonly miscoded cases.
• Work arising from a condition-monitoring alarm. A vibration trend crosses an alarm threshold and a bearing replacement is raised. Again, the monitoring is preventive or predictive. The bearing job is corrective.

That last pair is worth dwelling on, because it dismantles the idea that corrective maintenance sits at the bottom of a maturity ladder. A mature, well-instrumented, heavily preventive operation generates more corrective work orders than a neglected one, not fewer, because it finds more faults earlier. The difference is that in the mature operation almost all of that corrective work is planned, scheduled and unhurried, whereas in the neglected operation it arrives as emergencies. Same category, completely different experience. If you want the quadrant that separates those two dimensions properly, that is the subject of the planned versus unplanned maintenance guide, and I will not re-teach it here.

2. Corrective maintenance is not corrective action

One quick disambiguation, because the two phrases collide constantly in organisations that run a quality management system alongside a maintenance function. Corrective maintenance restores a physical item to its required function after a fault. Corrective action, in the management-system sense, eliminates the cause of a nonconformity so that it does not recur. Replacing a failed bearing is corrective maintenance. Changing the lubrication specification so that bearings stop failing is corrective action. One fixes the item, the other fixes the system that let the item get into that state. They frequently follow one another, and an auditor asking for your corrective action records will not be satisfied with a pile of work orders. The distinction is set out at length in the corrective action versus preventive action guide.

3. The primary split: immediate versus deferred

If corrective maintenance has one internal division that matters more than any other, it is immediate versus deferred. European maintenance terminology (EN 13306:2017, "Maintenance, Maintenance terminology", published by CEN, with no ISO equivalent) supports exactly this distinction within corrective maintenance, and it is the most practically useful piece of vocabulary in the whole standard.

Immediate corrective maintenance is carried out without delay after the fault is detected, because the consequence of waiting is unacceptable. Deferred corrective maintenance is held back, deliberately and in accordance with given rules, until the work can be prepared and executed properly.

Note what that definition of deferred does not say. It does not say "when we get round to it". Deferral is a decision taken against rules, not an absence of a decision. That is the whole argument of this article.

4. The lifecycle of a corrective job, properly

A corrective work order has a life of its own, and most of the value or waste in the category is created at the two ends: the initial report and the final record. The middle, the actual spanner work, is usually the part organisations manage best and worry about most, which is the wrong way round.

The stages, in order:

• Fault identification and reporting. Someone notices something wrong and says so, in writing, in the system of record.
• Assessment and triage. A competent person decides what the fault means, against consequence and asset criticality, and sets priority.
• The immediate or deferred decision. The fork in the road, with everything the table above requires recorded at the moment of the decision.
• Planning and preparation. For deferred work: scope, method, parts, permits, access, trades, duration.
• Scheduling. Fitting the prepared job into a window where the asset and the crew are both available.
• Execution. Doing the work safely and to a standard.
• Recording and closure. Capturing what was found, what was done and what it cost, in a form that will still be useful to someone analysing failures three years from now.

I am deliberately not re-teaching work order types here, because the taxonomy question, how corrective sits alongside preventive, emergency, project and inspection order types in a real system configuration, is covered properly in the work order types in a CMMS guide. Read that for the coding structure. Read this for what happens inside a single corrective job.

5. The fault report, which determines everything downstream

The quality of the initial fault report sets a ceiling on the quality of everything that follows, and nothing else in the lifecycle is anywhere near as cheap to improve. A planner cannot plan a job that has not been described. A storeman cannot stage a part for a fault nobody characterised. A reliability engineer cannot analyse a history of records that say "not working".

"Not working" is the most expensive three syllables in maintenance. It forces a diagnostic visit that produces no repair, a second trip once the fault is understood, and often a third once the right part has arrived. Illustratively, a fault report that reads "AHU-07 supply fan, loud rumbling from drive-end bearing, increasing over about two weeks, unit still delivering air, noticed during morning round" lets a planner raise a bearing replacement with the right part, the right access arrangements and the right trade, in one visit. The same fault reported as "AHU noisy" produces three visits. That is not a software problem and it is not fixed by a better mobile app. It is fixed by telling people what a good report contains and then giving feedback when they do not provide it.

The minimum content I would ask for on any fault report:

• The asset, unambiguously. A tag number, not a location description. "The pump in the basement" is not an asset identifier.
• The symptom, specifically. What is observed: noise, leak, vibration, alarm text, smell, heat, no output, intermittent output.
• The functional impact. Is the asset still delivering its function, partly delivering, or not delivering? This is the single field that most changes triage, and it is the field most often left blank.
• When and how it was noticed. Sudden or gradual, during operation or during an inspection, first occurrence or a repeat.
• Any immediate action already taken. Isolated, bypassed, load transferred, area cordoned, nothing.

Whether that arrives through a mobile app, a helpdesk call, a paper slip or a control-room log matters far less than whether those five things are present. Any competent maintenance system can capture them. Most are configured so that none of them is mandatory.

6. Assessment and triage against consequence

Triage is where a raw fault report becomes a prioritised job, and the mistake I see most often is priority being set by the reporter's tone of voice rather than by consequence. The person who reports loudest gets the crew. That is not a priority system, it is an escalation lottery.

A defensible triage runs the fault against two axes. First, the consequence of the fault continuing: safety, environmental, statutory or contractual, operational output, cost, and reputational. Second, the criticality of the asset, which is a property of the asset established in advance and independent of who is reporting today. A high-consequence fault on a high-criticality asset is immediate. A low-consequence fault on a low-criticality asset is deferred without much debate. The interesting cases are the diagonals, and those are the ones that deserve a named decision-maker rather than a rule.

Two practical points. Assess the fault, not the asset: a minor cosmetic fault on a critical asset is still a minor fault, and pretending otherwise inflates the emergency queue. And assess the rate as well as the state: a bearing that has gone from acceptable to alarm in ten days is a different proposition from one that has sat just inside alarm for a year, even though today's reading is the same.

7. What a defensible deferral looks like on paper

A deferral you cannot defend is worse than no deferral, because the record proves you knew. Four things must be on the work order at the moment the deferral is taken, and they must be written by the person taking the decision rather than inferred later:

• What the fault is. The technical condition, in terms a third party can understand, with whatever measurement supports it.
• What the consequence of waiting is. Not "low risk". An actual statement: what happens if this is not repaired, how soon, and how bad.
• What interim control applies. Reduced duty, increased monitoring frequency, a temporary transfer of load, a restriction on operation, more frequent inspection, or explicitly none because none is needed.
• When it will be reviewed, and by whom. A date, a named accountability, and a trigger that would force an earlier review.

The review date is the load-bearing element. Deferral without a review date is abandonment, and the backlog is where good intentions go to die. A job deferred with a review date is a managed risk. The same job deferred with no date is an eighteen-month-old work order that somebody will eventually close in a data-cleanup exercise without anyone ever looking at the asset. The mechanics of ageing, segmenting and actually clearing that queue are the subject of the maintenance backlog and downtime tracking guide; what belongs here is the narrower point that the review date has to exist at the moment of deferral, not be added later when someone audits the backlog.

For deferred work that has been reviewed and held again, record the re-review as a new decision with its own reasoning. A job that has been rolled forward four times with no change in reasoning is telling you either that the original consequence assessment was wrong, or that the work is never going to be resourced and should be escalated as a decision rather than quietly re-deferred.

8. Planning and executing the deferred job

The reward for deferring properly is that the job can be prepared, and preparation is where corrective work stops being expensive. A prepared corrective job has a defined scope, a method, the parts on site and reserved, the permits raised, the access and isolation arranged, the right trades booked, and a realistic duration estimate. An unprepared one has a technician, a hope and a stores counter.

Two things I would insist on for any corrective job above trivial:

• Scope the repair, not the symptom. If the fault report says "leaking gland" and the planner writes a gland repack, the job may come back in six weeks because the shaft was scored. Planning a corrective job means asking what condition would have produced this symptom and scoping to cover the likely finding, with a decision point in the method for the worse case.
• Plan the verification. How will anyone know the required function has actually been restored? A reading, a run test, a functional check against the original specification. "Ran it, sounds fine" is not restoration of function, it is an opinion.

During execution, the thing that most reliably degrades the later record is the gap between what the technician found and what the technician wrote. A technician who discovers that the bearing failed because the drive was misaligned knows the single most valuable fact in the entire job, and if there is no convenient place to put it, that fact leaves site in their head.

9. Recording: the richest failure data you will ever own

The corrective work order is the single richest source of failure information an organisation has, and it is filled in badly in a great many organisations. That is not a criticism of technicians. It is a criticism of how the closure form is designed, what is mandatory on it, and whether anyone ever demonstrates that the data was used for anything.

International practice on structuring this data is well developed. ISO 14224:2016, "Collection and exchange of reliability and maintenance data for equipment", published for the petroleum, petrochemical and natural gas industries, sets out a taxonomy and data format for exactly this purpose, and its structure travels usefully well outside oil and gas. It grew out of the OREDA work, and it is worth being precise here: OREDA is a proprietary members-only database, not a standard. ISO 14224 is the standard. For the surrounding dependability vocabulary, mean time between failures, mean time to restoration and the rest, the formal home is IEC 60050-192:2015, which supersedes the 1990 edition of IEC 60050-191 that older documents still cite.

The structure that makes the coded part of this workable is the problem, cause and action triple, and it repays proper design rather than accepting whatever came with the system. That is covered in detail in the failure codes guide. The point I would add from a corrective-work perspective is this: a code list that a technician cannot complete honestly in under a minute will be completed dishonestly in under ten seconds, and you will have worse data than if you had asked for nothing but free text.

10. The temporary repair problem

Every practitioner recognises this. The strap holding a bracket. The clamp on a pipe. The jumpered contact. The interlock that has been bypassed so the line could run. Temporary repairs are a legitimate part of corrective maintenance, because sometimes restoring function now with an imperfect fix is genuinely the right engineering call. What is never legitimate is a temporary repair that has become invisible.

The discipline is straightforward to state and hard to sustain:

• Record it as temporary. A flag on the work order, not a note buried in free text. If your system has no such flag, that is a configuration gap worth closing.
• Raise the permanent repair at the same time. Not later, not when there is time. The same shift, linked to the temporary job, so the permanent work exists in the backlog with its own priority.
• Give it a review date and an owner. The same four-part deferral record described above applies, because a temporary repair is a deferral with hardware attached.
• Mark it physically. A tag on the asset so the next person to work on it knows. Institutional memory is not a control.
• Never close it as complete. A temporary repair closed as complete has removed itself from every report that would have surfaced it. This is how organisations end up genuinely unaware of how much temporary work is holding their plant together.

A short register of live temporary repairs, reviewed at the same meeting that reviews backlog, is one of the highest-value low-effort controls available to a maintenance manager. It usually produces a moment of unwelcome clarity the first time it is compiled.

One category must be separated out entirely. A bypassed protective device is a safety matter, not a maintenance shortcut. Defeating an interlock, a trip, a guard switch, a pressure relief arrangement or a fire or gas detection function is not a temporary repair in the ordinary sense and must not be managed as one. It belongs under a controlled override or impairment process, with a documented risk assessment, competent authorisation at an appropriate level, compensating measures in place for the duration, a hard time limit, and a register that someone is accountable for clearing. Which process applies, and who is competent to authorise it, depends on your jurisdiction, your sector and your own safety management system, and that is a question for your safety function rather than for a maintenance article. What is not jurisdiction-dependent is the principle: this decision sits above the maintenance supervisor's authority, and a maintenance system's temporary-repair flag is not a substitute for it.

11. Corrective work as a feedback signal

Corrective maintenance is not an endpoint. Done properly it is the richest input to every improvement mechanism the organisation has, and treating it as a cost to be minimised rather than a signal to be read is the difference between an operation that gets more reliable and one that just gets busier.

Three specific loops are worth naming:

• Repeat corrective work triggers root cause analysis. The same fault on the same asset, or the same fault across a population, is the clearest trigger there is. Set a threshold in advance so it fires automatically rather than depending on someone noticing. For the method, the root cause analysis guide walks the process, and it is worth knowing that a genuine international standard exists here: IEC 62740:2015 covers root cause analysis and describes several recognised techniques, including the "Why" method and the Ishikawa diagram, so the common claim that RCA is unstandardised is simply wrong.
• Corrective findings tell you a preventive task is wrong. If a preventive routine passes an asset as satisfactory and corrective work on that same asset arises weeks later from a condition the routine should have caught, the routine's content or interval is wrong. That is not a failure of preventive maintenance as a concept, it is the feedback signal that preventive maintenance needs to stay calibrated. For the surrounding strategy vocabulary, the preventive versus predictive versus reactive comparison sets out how the categories relate.
• Corrective history is the input to defect elimination. Not fixing faults faster, but designing out the conditions that create them: a change of material, a change of specification, a change to how the asset is operated. This is where corrective maintenance stops being maintenance and becomes engineering, and it is the mechanism behind most durable improvement in equipment reliability.

Where asset management is being formalised around a management system, the relevant family is ISO 55000:2024 and ISO 55001:2024, with ISO 55002:2018 as the implementation guidance, still on its 2018 edition at the time of writing. The corrective work record is one of the more obvious places where an asset management system either has real evidence of how assets are being looked after, or has a procedure and nothing behind it.

12. Measuring corrective work without gaming it

I am deliberately publishing no target figures in this section, and I would be wary of anyone who offers you one. There is no credible universal benchmark for corrective work mix, backlog age or repeat rate, because the right number depends on your asset base, your redundancy, your operating context and your risk appetite. Targets have to be set against your own baseline and moved deliberately from there. What I can offer is which measures actually tell you something.

• Corrective work as a share of total work. Useful, and routinely misread. A rising corrective share can mean deteriorating assets, or it can mean a newly effective inspection programme finding faults it previously missed. The number is uninterpretable on its own. Split it by whether the corrective work was immediate or deferred, and the picture becomes readable: a rising deferred share with a stable immediate share is usually good news.
• Backlog age for deferred corrective work. Not backlog size, age. Size tells you about capacity; age tells you about decisions you have not made. A deferred corrective job past its review date is the specific thing worth counting, because that is the measure of whether deferral is being managed or is just a filing location.
• Repeat corrective work rate. The proportion of corrective jobs that are a return visit to a fault previously reported as resolved. In my view this is the most informative of the three by a distance, because unlike the other two it is very hard to improve except by actually fixing things properly. It resists gaming in a way that volume and compliance measures do not, and a falling repeat rate is almost always real improvement.

On gaming generally: any corrective measure attached to an individual's performance will corrupt the data that feeds it. If technicians are judged on how many corrective jobs they close, jobs get closed. If they are judged on how few emergencies occur, emergencies get recoded. Measure the process at the level where the process is managed, and keep the closure record itself out of anyone's personal scorecard.

The idea to walk away with

Corrective maintenance is not breakdown work and it is not a mark of immaturity. It is the whole category of work that follows the detection of a fault, most of which in a well-run operation is found early, on running equipment, by people who were looking. The two decisions that define how well you manage it are both decisions about information rather than about spanners: whether the fault was described well enough at the start to be planned, and whether what was found was recorded well enough at the end to be learned from.

And the deferral decision is the one to get proud about. An operation that can look at a fault, assess it honestly, apply an interim control, book a review date and hold its nerve is doing something considerably more skilled than an operation that reacts to everything immediately. Deferral with a review date is control. Deferral without one is just a slower way of being surprised.

Final thoughts

If you want one practical place to start, take a sample of fifty closed corrective work orders from the last quarter and read the free-text closure notes. That exercise tells you more about the health of your maintenance function than any dashboard will, and it costs an afternoon. Count how many tell you what was actually found, how many tell you what caused it, and how many say some variant of "fixed". Then take the same fifty and check how many of the deferred ones ever had a review date. Whatever you find, that is your real starting position, and it is a far more honest baseline than any benchmark somebody else's plant produced.

The wider posture questions, whether reactive operation is ever a defensible choice and how run-to-failure is decided as a strategy, are a different subject and are covered in the reactive maintenance guide, while the mechanics of responding to an actual breakdown event belong in the breakdown maintenance guide. This article has stayed inside the corrective job itself, because that is where most of the recoverable value sits and it is the part that gets the least deliberate attention.

Reference documents worth having to hand, all paywalled and all worth reading in the original rather than in somebody's summary: CEN / CENELEC for EN 13306 maintenance terminology, ISO for ISO 14224 and the ISO 55000 family, and IEC for the dependability vocabulary and the root cause analysis standard. Check the current edition before citing any of them; several in this area have been revised recently and older designations are still widely repeated.

Related reading: Planned vs unplanned maintenance, Reactive maintenance: a complete guide, Breakdown maintenance: a complete guide, Work order types in a CMMS, Failure codes: Problem, Cause, Action, Maintenance backlog and downtime tracking, Root cause analysis methods, Corrective action vs preventive action, Equipment reliability and how to improve it, Preventive vs predictive vs reactive.