Reliability KPIs & Performance Measurement

Source and Scope Boundary#

This page is the public derivative of `RM-MKS-7013 — Reliability KPIs`, v0.3, Approved Internal. It owns the reliability-engineering KPI set: MTBF, MTTR, Inherent Availability, Failure Rate, and the cumulative-failure trend concept. Operational maintenance-management metrics — PM compliance, schedule compliance, backlog age, wrench time — belong to Maintenance KPIs. Deep statistical treatment (confidence intervals, censored data, Weibull/distribution shape) belongs to the reliability-analysis topics, not here. This page defines these measures at a working level.

Plain-English Definition#

Reliability KPIs answer three linked questions about a defined, repairable population over a defined period:

• How often does it fail? — failure frequency (MTBF, Failure Rate)
• How quickly is it restored? — recovery speed (MTTR)
• What is the combined effect? — Availability

The single most important rule: report MTBF, MTTR, and Availability together, never one alone. MTBF and MTTR measure different things, and improving one does not improve the other; Availability is what shows their combined effect. Every number must carry its population definition, observation period, and qualifying-failure taxonomy — these statistics are highly sensitive to how the population and event boundaries are defined.

Why It Matters#

A single reliability number with no context invites gaming and misreading. A "good" MTBF can hide a worsening trend; a low MTTR can hide wait-for-parts time that operations still feels as full downtime; a fleet average can bury a bad actor. Reported as a disciplined set with stated definitions, these KPIs point maintenance and reliability effort where it will actually help — and, just as importantly, tell you where *not* to look.

No universal target is asserted. Realistic values vary enormously with asset type, duty cycle, environment, and design.

Leading and Lagging Indicators#

A balanced program uses both, but "leading" is a claim to be earned, not a label:

• A leading indicator has a documented predictive relationship to a later outcome in your context — it is not proven predictive just by being called leading.
• A lagging indicator describes an outcome after the event; the same measure can support forward decisions when trended.

MTBF, MTTR, Failure Rate, and Availability are outcome (lagging) measures; their trends are what make them useful for forward decisions.

The Reliability KPI Set#

All examples below use one worked population: 10 identical continuous-duty process pumps, observed for one calendar year. Each pump has 36 planned-outage hours excluded, giving `10 × (8,760 − 36) = 87,240` operating hours. During the year, 7 events met the qualifying-failure definition, consuming 91 hours of restoration time.

Mean Time Between Failures (MTBF)#

MTBF = Total Operating Hours ÷ Number of Qualifying Failures

`87,240 ÷ 7 ≈ 12,463 hours`

Measures failure frequency for a repairable population. Exclude planned-outage hours from operating time; count only qualifying failures. MTBF is an average interval — it does not describe the shape of the failure-time distribution and is not a prediction of when the next specific asset will fail. With only 7 events, treat the result as directional, not precise.

Mean Time To Repair / Restore (MTTR)#

MTTR = Total Repair/Restoration Hours ÷ Number of Qualifying Failures

`91 ÷ 7 = 13 hours`

Measures maintainability/recovery speed. State the clock: the default is full restoration time (detection → verified return-to-service, including diagnosis, logistics/wait, repair, test). If a site instead tracks active repair/wrench time only, label it explicitly (the full-clock version is often called Mean Down Time, MDT) so the two are never silently mixed. A short mechanical repair can still mean a long interruption if wait time is excluded.

Inherent Availability#

Inherent Availability = MTBF ÷ (MTBF + MTTR)

`12,463 ÷ (12,463 + 13) ≈ 0.9990 = 99.90%`

Combines MTBF and MTTR into the fraction of time the population is capable of performing its function. It is derived from the two measures above — no separate raw data. Because a single blended figure can mask which lever moved (a stable Availability can hide a worsening MTBF offset by an improving MTTR), always publish all three together. If MTTR uses the full-restoration clock, the result approaches operational/achieved availability rather than strict inherent availability — state which when you publish it.

Failure Rate (λ)#

Failure Rate = Number of Qualifying Failures ÷ Total Operating Hours = 1 ÷ MTBF

`7 ÷ 87,240 ≈ 0.080 failures per 1,000 operating hours` (≈ 0.7 failures per pump-year across 10 pumps)

The reciprocal of MTBF, useful for summing across dissimilar time bases and comparing with rate-based reliability formulas. A constant failure rate is a convenient reporting assumption, not a verified fact — whether the rate is actually constant, rising, or falling with age is a distribution-shape question for Weibull/trend analysis, not for this single number.

Cumulative-Failure Trend (MCF) — concept only#

Plotting cumulative failures against cumulative operating time shows whether a population's failure rate is trending up (accelerating — aging, wear-out, or PM backlog), down (improving after a fix), or flat (stable/random). Use it as a visual read to decide where to investigate; rigorous trend determination uses formal reliability-growth methods, not eyeballing the curve.

Reading the Trend#

Interpretive guidance — a starting hypothesis for investigation, not a conclusion:

Neither pattern is confirmed without investigating the underlying events; the guidance says where to look, not what the answer is.

Common Failure Modes and Gaming#

Best Practices#

• Define population, observation period, and qualifying-failure taxonomy before calculating anything.
• Publish MTBF, MTTR, Failure Rate, and Availability together, with inclusion/exclusion rules visible.
• State the MTTR clock (repair vs restoration) and apply it consistently.
• Segment by asset class and duty cycle before aggregating a population-level KPI.
• Reconcile CMMS downtime records against an independent operating-hour source periodically.
• Flag small-sample results as directional; route rigorous uncertainty and distribution-shape questions to the dedicated statistical methods.
• Keep reliability-KPI scope separate from operational maintenance-management KPI scope.

Maturity Model#

Reporting#

Every reliability-KPI report should state: population definition, observation period, operating-hour source, qualifying-failure taxonomy version, MTBF, MTTR (with clock stated), Failure Rate, Inherent Availability, change vs prior period, a small-sample caution where the failure count is low, and a link to the underlying records. Do not show a favorable status indicator when material data (estimated run-hours, unresolved reclassification disputes) is missing or stale. Show MTBF and MTTR trend lines together — never MTBF alone.

Audit Questions#

• Is the population and observation period documented and current?
• Is the qualifying-failure taxonomy approved and version-controlled?
• Is the operating-hour source reconciled against an independent record?
• Is the MTTR clock definition (repair vs restoration) stated and applied consistently?
• Are MTBF, MTTR, Failure Rate, and Availability always published together?
• Are small-sample results flagged as directional?
• Were reclassifications of failure events approved and evidenced?

Practical Example#

A plant tracks the 10-pump population above. Over three quarters, fleet MTBF shortens from about 15,000 to 12,500 hours while MTTR stays flat near 13 hours. Following the trend guidance, the reliability engineer investigates PM backlog first rather than assuming a maintainability problem — and finds a growing count of deferred lubrication PMs. The KPI trend could not establish that link on its own; it pointed to where the answer was. No specific outcome is claimed.

Related Reliability Method Topics#

• Reliability Engineering
• Maintenance KPIs (operational maintenance-management metrics)
• Equipment History
• Condition Monitoring & Predictive Maintenance
• Failure Analysis & Failure Mechanisms

References#

References trace to the authoritative MKS; the MTBF/MTTR/Availability formulas reflect general reliability-engineering practice, and no numeric benchmark or target is asserted.

• RM-MKS-7013 — Reliability KPIs
• ISO 14224 — Collection and Exchange of Reliability and Maintenance Data (structured reliability/maintenance data; sector-scoped)
• SMRP Body of Knowledge (verify current licensed edition; no copyrighted content reproduced)

Revision History#