PlantOps BI

KPI Library / Production

MTBF (Mean Time Between Failures)

Formula: Total operating time ÷ number of failures
Typical range: Varies by asset complexity; track the trend on a fixed failure definition rather than chasing an absolute hours target

MTBF measures the average operating time between unplanned equipment failures, calculated as total run hours divided by the number of failure events in that period. It’s a reliability metric, not a maintenance-activity metric: a line with a busy maintenance team and a low MTBF is not being well maintained, it’s failing often.

What good looks like

MTBF has no universal target because a simple conveyor and a five-axis CNC don’t fail at comparable rates. What matters is the trend for a given asset against its own history, on a fixed and documented definition of “failure.” An asset with MTBF climbing quarter over quarter, tied to a reliability program (PM compliance, root-cause closure, spare parts availability) is doing the right things.

The number is trivially easy to game by narrowing what counts as a failure. Reclassifying a stoppage as “operator error” or “material shortage” instead of “equipment failure” makes MTBF look better without the asset getting any more reliable. Lock the failure taxonomy before you start trending, and audit reclassifications the same way you’d audit any other metric people are incentivized to move.

MTBF in Power BI (DAX)

With a maintenance events fact logging failure events by asset, and an hourly production fact carrying run time:

Total Run Hours =
DIVIDE ( SUM ( fact_production_hourly[run_minutes] ), 60 )

Failure Count =
CALCULATE (
    COUNTROWS ( fact_maintenance_events ),
    fact_maintenance_events[event_type] = "Unplanned Failure"
)

MTBF Hours =
DIVIDE ( [Total Run Hours], [Failure Count] )

Filter both measures to the same asset and the same date range using dim_date and dim_asset, and never let Failure Count reach zero without a note. A blank MTBF because nothing failed this week reads very differently from a blank MTBF because the data didn’t load.

Common mistakes

  1. Redefining “failure” without documenting the change. MTBF jumps that coincide with a change in maintenance’s logging practice aren’t reliability improvements.
  2. Mixing planned and unplanned stops in the failure count. A changeover isn’t a failure; if it’s counted as one, MTBF understates true reliability.
  3. Averaging MTBF across dissimilar assets. A conveyor’s MTBF and a robot’s MTBF live on completely different scales; blending them into one plant-level number hides which asset actually needs attention.