MTBF — Mean Time Between Failures

How AssetAI Calculates It — and Why the Window Matters

MTBF on the Analytics page is not a one-time report you generate — it's a live tile recalculated over a rolling window you choose: 30, 90, 180, or 365 days, with 90 as the default. The two numbers behind the ratio come straight from work-order data, not manual entry:

• Total time — the calendar span of the selected window.
• Failure count — every BM (breakdown maintenance) and CM (corrective maintenance) work order closed against that asset in the window.

Because BM/CM work orders in AssetAI cannot close without a recorded failure cause and remedy, the failure count feeding MTBF can't be inflated by closing a breakdown ticket with blank fields. That's a small but important integrity check — a reliability number is only as trustworthy as the failure log behind it.

One thing worth internalising before you act on the number: MTBF at 30 days and MTBF at 365 days for the same asset can look very different, because both the time base and the failure count shift with the window. A single bad week can crater the 30-day figure while barely denting the 365-day one. Compare an asset's MTBF against itself across windows, and against similar assets in the same window — never across two different windows.

What MTBF Won't Tell You On Its Own

MTBF is a historical average, not a forecast — it tells you how an asset has behaved, not when its next failure will land. A few limits worth planning around:

• It doesn't separate planned downtime (Idle, Standby) from unplanned failure time inside the formula itself — that distinction lives in the asset's status history, so if you need "failures vs. planned stops" as separate views, look there rather than expecting the MTBF tile to split it for you.
• It doesn't run per-failure-mode — there's no Weibull curve or bathtub-curve output, so you won't get a breakdown of "bearing failures vs. electrical faults" from this KPI alone.
• Unless an asset is on a usage/meter-based schedule logging actual readings, "total time" is calendar time in the window, not a continuous sensor-fed uptime count — a distinction that matters for assets with heavy idle time.

Because of this, MTBF is best read next to the other tiles on the same set — availability, MTTR, PM compliance, downtime hours, and downtime cost — all computed from the same work-order and downtime event stream. If MTBF is falling while MTTR holds steady, you're looking at a frequency problem, not a repair-speed problem. That framing matters more than the raw number itself, and it's the same logic behind broader reliability practices like TPM.

Using MTBF to Decide PM Coverage

For Indian plants juggling mixed-age fleets — a common reality across manufacturing industries tracked by IBEF — the practical use of MTBF is deciding where reactive maintenance is fine and where it's costing more than a preventive plan would. Pair it with:

• RRR criticality scoring, which looks at breakdown/corrective failure counts over a 12-month window to flag assets due for repair, review, or replacement.
• OEE, since a low-MTBF asset is often also dragging down OEE through repeated unplanned stops rather than slow cycle time.

If you're still mapping which KPIs matter for your fleet, book a 30-minute demo on your own plant data — not a slide deck — or browse free downloads for a broader primer on reliability metrics before you standardise on one.

Reading MTBF Next to MTTR, Availability, and PM Compliance

MTBF was never designed to be read alone, and AssetAI doesn't present it that way — it sits on the same tile set as MTTR, availability, PM compliance, downtime hours, and downtime cost, all computed from the same underlying work-order and downtime data. That adjacency is deliberate:

• MTBF tells you how often an asset fails.
• MTTR tells you how fast it gets fixed once it does.
• Availability combines both into the share of scheduled time the asset was actually usable.
• Downtime hours and cost translate the same failure events into hours lost and rupees spent.

A long MTBF with a long MTTR can still produce poor availability — the asset fails rarely, but each failure is expensive in time. A short MTBF with a short MTTR might actually be more tolerable on the shop floor than the numbers suggest in isolation. Reading these four or five tiles together, rather than fixating on MTBF as a standalone score, is closer to how reliability engineering is meant to work — the same logic behind broader frameworks like Total Productive Maintenance and OEE, which also refuse to reduce equipment health to a single figure.

Who Actually Uses This Number, and For What

A worked example helps ground the formula: an asset that ran 600 hours in the window and logged 3 failures has an MTBF of 200 hours — that's arithmetic, not a claim about any specific machine or customer. What matters more than the example is who reaches for this number and why:

• Maintenance heads and reliability engineers scan MTBF across the asset list on Analytics to flag which machines are failing often enough to justify a change in maintenance strategy.
• Planners weigh MTBF alongside the RRR (Repair/Review/Replace) criticality score — a separate view that looks at breakdown and corrective failure counts over a 12-month window — before deciding whether an asset class deserves preventive coverage or can stay on reactive maintenance.
• Auditors and quality teams, especially at plants aligning with ISO standards or referencing AssetAI's own ISO & standards documentation, use MTBF trends as supporting evidence that failure data is being captured consistently, not backfilled.

For Indian manufacturing plants juggling multiple shifts, contract labour, and mixed vintage equipment — the operating reality covered in industries — MTBF is one of the few KPIs that's cheap to compute and hard to argue with, provided the failure log behind it stays honest. If you want to see how it looks against your own asset list rather than a generic example, book a demo or browse the broader feature set.