What Is Reliability Engineering? A Complete Guide

Search the phrase "reliability engineering" today and you get two professions wearing the same name. One of them keeps pumps, chillers, switchgear, conveyors and building plant doing what they were installed to do. The other keeps web services online. They share a vocabulary of availability and failure and almost nothing else: different failure physics, different cost structures, different tools, different career paths. This guide is about the first one, physical-asset reliability engineering, the discipline practised in plants, utilities, process facilities and large building portfolios.

If you arrived here looking for Site Reliability Engineering, the software discipline that emerged from Google's operations practice and concerns itself with error budgets, service level objectives, observability and incident response on distributed systems, this is not that article and I am not going to pretend to cover it. SRE borrowed the word "reliability" honestly, because the underlying question is genuinely similar, but a bearing degrades and a container does not, and the analytical machinery is not transferable. Go and read SRE material written by people who do it. Everything below concerns metal, rotating parts, insulation, lubricant and the organisations that own them.

The message up front: maintenance restores and preserves function. Reliability engineering asks why the function fails at all, and changes the answer. That is the whole distinction, and everything else in this guide follows from it. The second most important idea is that inherent reliability is set at design and selection, and no maintenance regime on earth exceeds it. If you only take two things away, take those.

1. Two disciplines, one name: which one you want

The naming collision matters practically, not just semantically. Job adverts, university modules, certification schemes and search results are all now mixed. A facilities manager searching for reliability engineering training can end up in a cloud-computing syllabus, and a software engineer can end up reading about Weibull distributions and lubricant particle counts. Both then conclude the field is incoherent, when in fact there are simply two fields.

Physical-asset reliability engineering is the older of the two by decades. Its roots are in military and aerospace dependability work in the middle of the twentieth century, and its modern industrial form was consolidated in the aviation maintenance studies that produced reliability-centred maintenance. Its subject is hardware that wears, corrodes, fatigues, overheats, loses lubrication and eventually stops doing its job. Its practitioners carry titles like reliability engineer, plant reliability engineer, mechanical reliability engineer or asset reliability specialist, and they sit in operations, engineering or asset management functions.

The vocabulary of the physical discipline has a formal home: IEC 60050-192:2015, "International electrotechnical vocabulary, Part 192: Dependability", which supersedes the 1990 edition published as IEC 60050-191. A document citing IEC 60050-191 is working from a vocabulary a decade out of date. I will not reproduce its definitions here, because it is paywalled and quoting normative wording nobody purchased is not fair use of it, but it is the reference to borrow if your organisation argues about terms.

2. What reliability engineering actually is

The shortest useful definition: reliability engineering is the engineering discipline concerned with the probability that an item performs its required function, under stated conditions, for a stated period. Unpack that sentence and you have most of the discipline in it.

• Probability, because reliability is statistical. A single pump either runs or it does not. Reliability is a statement about populations, or about one item across many opportunities to fail. That is why the discipline is quantitative, and why it is uncomfortable for people who want a yes or no answer.
• Required function, because reliability is defined against what the asset must do in its specific context, not against a generic notion of working. The same pump model in two duties has two reliability problems.
• Under stated conditions, because operating context is part of the specification. Ambient temperature, duty cycle, water chemistry, dust loading, voltage quality and operator behaviour all belong in the statement. A reliability figure quoted with no operating context is decoration.
• For a stated period, because reliability is time-bounded. Reliable over a shift, a year, a design life and a twenty-year concession are four different claims.

What the discipline does with that definition is a loop. Understand what the asset must do. Establish how it can fail to do that. Understand the consequences of each way it can fail. Decide what, if anything, is worth doing about each one. Do it. Measure whether failures actually reduced. Feed the answer back. Organisations get stuck between the deciding and the measuring, which is the part that needs management support rather than technical skill.

3. How it differs from maintenance management

Maintenance is a delivery function: restore function when it is lost, preserve it while it exists, on time, safely, within budget, with the right parts and the right competence. A maintenance manager who does that well is doing a valuable job. Reliability engineering is an analytical function: change the frequency and consequence of the failures maintenance is being asked to fix. It succeeds by making maintenance work unnecessary, not by doing it faster. The two conflict constantly because they optimise on different timescales, maintenance judged this week and reliability over years. That tension is healthy until one function absorbs the other.

A practical test when someone tells me they have a reliability function: ask what it changed last quarter. If the answer is a list of completed analyses, it is a reporting function. If it includes PM tasks deleted, intervals changed, a specification upgraded, a spare newly stocked or a modification installed, it is a reliability function. For the strategy layer between the two, see preventive vs predictive vs reactive maintenance.

4. The core concepts: function, failure mode, effect, consequence

Four terms carry almost all the analytical weight in this discipline, and getting them straight is the single highest-value hour a maintenance team can spend.

• Function: what the asset is required to do, expressed with a performance standard. Not "the pump pumps water" but "deliver at least the required flow at the required head into the ring main, continuously, at the stated water temperature". Functions include secondary ones people forget: contain the fluid, stay below a noise limit, protect the operator, provide indication, meet a discharge consent.
• Functional failure: inability to deliver a function to its performance standard. A pump delivering eighty per cent of required flow has not stopped, but if the standard is full flow it has failed functionally. Total and partial failure are both functional failures, and they often have different causes and remedies.
• Failure mode: the specific way the functional failure occurs. Impeller wear. Bearing seizure through lubricant starvation. Seal degradation from abrasive solids. Coupling misalignment. Winding insulation breakdown. A useful failure mode names a mechanism, not a symptom. "Pump not working" is not one. "Bearing failure" is barely one. "Bearing failure due to lubricant contamination from a failed seal" is one you can act on.
• Failure effect: what happens when that mode occurs. What the operator sees, what the alarm does, how long it takes to notice and to put right. Descriptive, not evaluative.
• Failure consequence: what the effect matters for. Safety and environment, statutory compliance, output, secondary damage, repair cost. Consequence is the only rational basis for deciding how much to spend preventing something, which is why every serious framework sorts failures by consequence before deciding on tasks.

This is also why identical assets legitimately carry different maintenance regimes. It looks like inconsistency on a spreadsheet; it is context being respected. The corollary is uncomfortable: a standardised PM library rolled out across a portfolio by asset type, with no reference to duty or consequence, is not reliability engineering even if a reliability engineer built it.

5. The measurement layer, in summary

Reliability engineering is quantitative, so it needs a small set of measures. I am keeping this to orientation depth deliberately, because each has a dedicated guide on this site that goes deeper than a pillar article should.

• Failure rate: failures per unit of exposure, usually operating time. The most fundamental measure, and the one whose shape over an asset's life produces the familiar bathtub discussion. See failure rate formula and calculation and the bathtub curve explained.
• MTBF, mean time between failures: total operating time divided by the number of failures, for repairable items. Useful as a trend on a population, routinely abused as a prediction for an individual asset. See MTBF explained.
• MTTF, mean time to failure: the equivalent for items that are replaced rather than repaired. The distinction between MTBF and MTTF is not pedantry, it changes which statistical treatment is valid.
• MTTR, mean time to repair or restore: the average time to bring function back. See MTTR meaning and formula.
• Availability: uptime divided by the sum of uptime and downtime, which combines how often things fail with how long they take to fix. Availability is a systems property, not an equipment property, and confusing it with reliability causes real decision errors. See reliability vs availability vs maintainability and the combined reliability metrics guide.

6. The analysis toolkit, and which question each tool answers

The toolkit looks intimidating as an acronym list and becomes manageable once each tool is attached to the question it answers. Nobody uses all of these, and using the wrong one is a common and expensive mistake: a full RCM study where a focused bad-actor analysis would have done, or a five-whys session where the real question was which assets matter.

Two observations from practice. The tools are sequential in logic even when they are not sequential in a project plan: criticality tells you where to look, FMEA what can go wrong there, RCM or a lighter policy review what to do about it, condition monitoring executes part of the answer, RCA handles what got through anyway, and life-data analysis tells you whether the whole thing is working. And the heavier the tool, the more often it is applied where a lighter one would have sufficed. Full RCM on a non-critical asset is an expensive way to conclude that you should keep doing roughly what you were doing.

7. Design versus operate: the ceiling you cannot maintain your way past

If I could get one idea across to every operations reader, it would be this one. Every asset has an inherent reliability determined before it ever ran: by its design, material selection, sizing against actual duty, manufacturing quality, the competence of its installation and commissioning, and the operating envelope it was specified for. Maintenance can protect that inherent reliability. Maintenance cannot exceed it. No PM interval, sensor, analytics platform or contractor makes an undersized pump adequately sized or an unsuitable material suitable.

The consequence for how effort is allocated is uncomfortable. A pump running permanently off its best efficiency point, because the system was designed around a flow that never materialised, will cavitate and eat seals and bearings no matter how disciplined its maintenance becomes. The reliability answer is a hydraulic change, an impeller trim, a variable-speed drive or a different pump. The maintenance answer is to keep replacing seals well. Only one of those stops the problem, and it is not the one most organisations are structured to deliver.

So a mature reliability function spends part of its time upstream, where it is less comfortable and more valuable:

• Specification review: does the proposed equipment suit the actual duty, ambient conditions and maintenance access available?
• Design for maintainability: can it be isolated, drained, lifted, aligned and instrumented safely without shutting down half the plant? Maintainability is a design property and it drives MTTR far more than technician skill does.
• Standardisation of selection: fewer variants means deeper spares coverage, better technician familiarity and more usable failure statistics. Procurement chasing the lowest unit price across many variants quietly destroys all three.
• Commissioning quality: a meaningful share of early-life failures are installation defects, not equipment defects. Precision alignment, correct lubrication, verified protection settings and honest witnessed testing at handover buy years.
• Operating discipline: running outside the envelope, frequent starting, running dry, bypassing protection and deferred cleaning are reliability decisions made by operations, not maintenance.

8. What a reliability engineer actually does all week

Job descriptions for reliability engineers are unhelpfully abstract, so here is a concrete picture of the work, whether the title is plant reliability engineer, mechanical reliability engineer or reliability lead. Proportions shift with industry and maturity; the activities are consistent.

• Bad-actor analysis. Pull the last period of corrective history and sort by repeat failures, downtime, cost and emergency response. A small number of assets generate a disproportionate share of unplanned work in most organisations. Those are the week's targets. Highest-return single habit in the discipline, and it needs no new technology.
• PM programme review. Task by task: does it address a real failure mode, does the interval have any basis, is it detecting anything, would deleting it be noticed. Good reviews delete tasks. An engineer who only ever adds PMs is inflating cost and calling it diligence.
• Defect elimination. Working the chronic annoyances nobody reports any more because they are routine: the valve that always passes, the sensor that always drifts, the drain that always blocks. Cheap to fix permanently, and collectively they consume an enormous amount of unrecorded effort.
• Criticality and spares strategy. Keeping the ranking current as duty changes and translating it into stocking decisions: which long-lead components must be on the shelf, and which can be bought on failure. Spares strategy is a reliability decision usually made by finance in the absence of one.
• Supporting RCA. Not owning every investigation, which does not scale, but setting the trigger threshold, facilitating the significant ones, holding the quality of causal reasoning, and tracking whether corrective actions were actually implemented. Unimplemented RCA actions are the most common failure of the whole practice.
• Condition monitoring oversight. Reviewing routes, thresholds and findings, checking detections convert into planned work rather than accumulating in a dashboard, and retiring monitoring that has never found anything.
• Reviewing new and modified assets. Commenting on specifications, maintainability, spares, instrumentation and handover documentation before commitment, not after installation.
• Defending changes with data. A larger part of the job than newcomers expect. Deleting a PM task, extending an interval, changing a specification or refusing a monitoring purchase all need a defensible written case, because someone will eventually ask why. The engineers who last are the ones who write things down.

Note what is not on that list: doing maintenance. An engineer who spends the week being pulled onto breakdowns is not doing reliability engineering, they are an extra supervisor with an analytical job title. That is structural, not personal.

9. Data quality: the binding constraint

Everything above runs on work-order history. Failure rate, MTBF, bad-actor ranking, PM effectiveness, life-data analysis and most RCA inputs come from what was recorded when work was executed and closed. So the binding constraint in most organisations is not analytical skill, tooling or budget. It is that the history is not trustworthy enough to analyse. The recurring defects I find when auditing maintenance history are consistent and unglamorous:

• No reliable distinction between corrective and preventive work, which makes any reactive-versus-planned analysis meaningless.
• Failure coding absent, optional or free-text. If the cause field is blank on most closed corrective orders, you cannot analyse failure modes at all, and no amount of software licensing changes that.
• Downtime not captured, or captured as the duration of the work order rather than the duration the function was unavailable. Those are different numbers and only one of them is availability.
• Work recorded against the wrong level, typically a building or system rather than the asset, so failures cannot be attributed to the item that actually failed.
• Closure comments carrying the real information, unstructured and therefore invisible to analysis. "Replaced bearing, found seal gone again" is the most valuable sentence in the record and it is in a free-text box.

This is where software unavoidably enters a reliability discussion, so let me keep it generic and brief. Whatever maintenance system you run, the reliability question of it is narrow: does it capture a structured failure code on corrective work, does it record function-unavailable time separately from labour time, does it hold a stable asset hierarchy, and can you get the history out for analysis without begging. Most systems can be configured to do all four. Most are not, because the configuration decisions were made to speed up work-order closure rather than to enable analysis later. That trade-off is made once at implementation and paid for over the following decade. If you are at that stage, the CMMS buyer's introduction covers the ground.

There is a published standard for the structure of this data. ISO 14224:2016, "Petroleum, petrochemical and natural gas industries, collection and exchange of reliability and maintenance data for equipment", third edition, defines an equipment taxonomy and data format for exactly this purpose. Its taxonomy reflects its home sector, but the discipline of its approach travels well into utilities and heavy facilities. One correction worth making because it is repeated constantly: OREDA is a proprietary, members-only reliability database, not a standard. ISO 14224 is the standard that grew out of that work.

10. The standards landscape, and its limits

Is any of this standardised? Partly. Here is the accurate picture, with designations given exactly and status noted, because misquoted standard numbers cause real confusion in tenders and specifications.

• Vocabulary. IEC 60050-192:2015, "International electrotechnical vocabulary, Part 192: Dependability", is the formal home of dependability terminology including the time-based measures. It supersedes IEC 60050-191:1990.
• RCM. SAE JA1011_202411, "Evaluation Criteria for Reliability-Centered Maintenance (RCM) Processes", issued November 2024, sets the criteria that determine what may legitimately be called RCM. It does not prescribe a process; it defines the questions any process must answer and the logic it must contain, so a method failing any criterion is not RCM whatever it is marketed as. SAE JA1012_201108 is the accompanying guide and is now a generation behind JA1011. IEC 60300-3-11:2009 is the international application guide for reliability centred maintenance.
• Analysis techniques. IEC 60812:2018, third edition, covers failure modes and effects analysis, FMEA and FMECA. IEC 61025:2006, second edition, covers fault tree analysis and is still the current edition. IEC 62740:2015 covers root cause analysis, describing principles, process steps and a set of recognised techniques. That last one matters because it is frequently claimed that RCA has no standard. It does.
• Maintenance terminology. EN 13306:2017, "Maintenance, maintenance terminology", is a European standard published by CEN with no ISO twin. It is the document that defines the maintenance type hierarchy most of the industry uses loosely: preventive maintenance splitting into predetermined and condition-based, with predictive maintenance defined as a form of condition-based, alongside corrective maintenance. Worth knowing because it settles the common argument about whether predictive and condition-based are the same thing.
• Data collection. ISO 14224:2016, as discussed above.
• Asset management. If reliability sits inside a formal asset management system, the family is ISO 55000:2024 for vocabulary, overview and principles, ISO 55001:2024 for requirements, which is the certifiable one, and ISO 55002:2018 for guidance on applying it. Note the mixed vintage: 55002 is still the 2018 edition and under revision. Note also that "ISO 55001:2014" appears constantly in consultancy material and is a decade out of date.

One qualification applying to all of the above, stated once. These are voluntary standards, and none is law anywhere by itself. They acquire force through contracts, client specifications, acceptance tests and management-system certification, not statute, and most are paywalled, which is why this article names designations and scope rather than reproducing clause text. Statutory obligations relating to equipment, whether workplace safety, pressure systems, lifting equipment or fire protection, sit in your own jurisdiction's instruments and are separate from everything above. Check the current published edition before citing any of these in a specification.

Primary sources worth bookmarking rather than trusting a summary of: IEC , ISO and SAE International .

11. Where reliability engineering sits, and why placement decides its fate

Capable reliability engineers fail in organisations that genuinely wanted reliability, and the cause is commonly structural. Three patterns account for most of it.

Reporting into a reactive maintenance function. If the engineer reports to the manager whose week is judged on breakdown response, the engineer will be pulled onto breakdowns. Not maliciously, just by gravity: the urgent outranks the analytical, and a manager under outage pressure who has a spare competent engineer will use them. Within months the analytical work exists only as good intentions. The fix is either reporting outside the reactive line, into engineering or asset management, or a protected time commitment a senior manager actually defends when it is tested.

No authority to change anything. A function that can recommend but not decide produces analyses that are read, complimented and shelved. At minimum it needs authority over PM programme content, a formal voice in spares stocking, and a mandatory review point on new and modified asset specifications. Without those three it is a research department.

Measured on activity. Counting analyses completed, studies run or monitoring points installed produces exactly those things and no reliability improvement. The function has to be measured on failure outcomes over a horizon long enough for them to move, which means a year or more, which means a sponsor patient enough to wait. That patience is among the strongest predictors of whether a reliability function survives.

The practical minimum for a function that will not quietly die: a named person with reliability as their actual job, protected analytical time that survives contact with a bad week, access to the maintenance history without gatekeeping, authority over the PM programme, and a sponsor senior enough to absorb the first year in which cost goes up before failures come down. Missing any one of those, I would rather see an organisation start smaller and honestly, with a monthly bad-actor review that actually happens, than announce a programme that will be dismantled by attrition.

12. What reliability engineering cannot do

An honest closing on the limits, because the discipline is oversold roughly as often as predictive maintenance is.

• It cannot exceed inherent reliability. Design and selection set the ceiling. The limit most often ignored.
• It cannot predict individual failures with certainty. Reliability is probabilistic. A well-run programme reduces how often and how badly things fail; it does not deliver a calendar of future breakdowns, and any promise that sounds like one is a sales claim.
• It cannot prevent failures with no detectable warning. Some modes develop over months and are visible to monitoring. Others are effectively instantaneous, and for those the answer is redundancy, protection, design change or accepting the consequence. Monitoring cannot detect what does not develop.
• It cannot fix operating behaviour it does not control. If assets are habitually run outside their envelope or with protection bypassed to keep output up, reliability analysis will keep identifying the same cause and keep being unable to act on it.
• It cannot substitute for competence and supply chain. Perfect analysis with no trained technicians, no correct parts and no access to the asset produces perfect documentation of failures you could not prevent.
• It cannot deliver quickly. Failure rates move over quarters and years. Anything promising a transformation in a quarter is either measuring something else or was starting from a very low base of basic discipline.
• It cannot make the economic case for itself everywhere. On low-consequence, cheap, easily replaced assets, analysing failure costs more than tolerating it. Running to failure is sometimes the correct engineering answer, and a reliability function that cannot say so has misunderstood its own purpose.

The idea to walk away with

Maintenance restores and preserves function. Reliability engineering asks why the function fails at all and changes the answer. Everything else, the metrics, the acronyms, the standards, the monitoring technology, is machinery in service of that one question. The function, not the equipment, is the unit of analysis, because functions carry performance standards and context while equipment carries only a nameplate. And the ceiling on what any of it can achieve was set before the asset ever ran.

Building this capability from nothing, the order I would recommend is unglamorous and cheap. Rank assets by consequence of failure. Pull the repeat-failure list from the history you already hold and work the top of it. Fix failure coding so next year's list is better than this year's. Review the PM programme against actual failure modes and delete what is not earning its place. Only then reach for the heavier tools. Most of the available improvement sits in those four steps, and none of them requires a purchase.

Final thoughts

Reliability engineering is not a technology and not a certification. It is a habit of asking why, applied consistently to physical assets, with enough data discipline to answer honestly and enough organisational protection to act on the answer. The technical content is learnable in months. The organisational conditions, protected time, real authority, outcome-based measurement and a patient sponsor, are what determine whether the function changes anything. The technical side is rarely the reason these programmes fail.

Coming to this discipline fresh, the most useful next step is not a tool or a course. Open your maintenance history, list the ten assets that generated the most unplanned work last year, and ask of each whether it is failing because it is not being looked after or because it was never right for the duty. That question, honestly answered ten times, will tell you more about where your reliability effort belongs than any framework will.

Related reading: Equipment reliability and how to improve it, Reliability vs availability vs maintainability, RCM: a practical introduction, FMEA guide, Root cause analysis methods, Reliability metrics: MTBF, MTTR, availability, The P-F curve explained, Equipment criticality analysis.