Maintenance & ReliabilityFree generatorPDF, Excel, Word export

MTBF and MTTR Python Script Generator for a Failure Log CSV

Most CMMS and ERP systems can export a list of breakdown work orders with start and end times, but few produce clean MTBF and MTTR per asset. This generator writes a short pandas script that does it from a CSV, runs on your own machine, and writes the result to a new CSV.

Fill in

Generated code
Download:

Python script (pandas)

import pandas as pd

CSV_FILE = 'failure_log.csv'
ASSET = 'asset_id'
START = 'breakdown_start'
END = 'repair_end'
PERIOD_START = pd.Timestamp('2026-01-01')
PERIOD_END = pd.Timestamp('2026-09-30') + pd.Timedelta(days=1)

df = pd.read_csv(CSV_FILE, parse_dates=[START, END])

# Keep failures that started inside the analysis period and have valid times
df = df.dropna(subset=[ASSET, START, END])
df = df[(df[START] >= PERIOD_START) & (df[START] < PERIOD_END)]
df = df[df[END] >= df[START]].copy()

# Repair duration in hours
df['repair_hours'] = (df[END] - df[START]).dt.total_seconds() / 3600.0

total_hours = (PERIOD_END - PERIOD_START).total_seconds() / 3600.0

g = df.groupby(ASSET).agg(
    failures=(START, 'count'),
    downtime_hours=('repair_hours', 'sum'),
    mttr_hours=('repair_hours', 'mean'),
)

# Assumes the asset is scheduled to run for the whole period; replace total_hours
# with real scheduled run hours per asset if you have them.
g['uptime_hours'] = total_hours - g['downtime_hours']
g['mtbf_hours'] = g['uptime_hours'] / g['failures']
g['availability_pct'] = 100.0 * g['uptime_hours'] / total_hours

g = g.sort_values('downtime_hours', ascending=False).round(2)
print(g.to_string())
g.to_csv('mtbf_mttr_by_asset.csv')

Formulas used

MTTR = total repair hours / number of failures
MTBF = (scheduled run hours - total downtime hours) / number of failures
Availability = (scheduled run hours - downtime hours) / scheduled run hours

Requires Python 3 and pandas (pip install pandas). Date columns must be parseable by pandas. The script assumes 24 hour scheduled operation over the whole period, which understates MTBF for assets that run one shift: replace total_hours with real scheduled hours. Assets with zero failures do not appear in the output, and their MTBF is not defined.

Reliability analytics on your ERP data

Optional: we can discuss refreshing MTBF, MTTR and downtime Pareto charts from your ERP automatically, on-premises.

Optional. The tool and every export work without this. No spam.

How to use it

Export breakdown work orders to CSV with one row per failure: asset, breakdown start and repair end as full date and time. Type the exact column names into the fields, set the period, copy the script into a file such as mtbf.py and run it in the same folder as the CSV. The output lists each asset with failures, downtime, MTTR, MTBF and availability, sorted by downtime so the worst assets are at the top.

  • One row per failure, not per labour posting
  • Use real timestamps, not dates only
  • Exclude planned work before exporting
  • Replace total_hours with real scheduled hours for non-24-hour assets

The formulas

MTTR is the average time to restore: total repair hours divided by failures. MTBF here is operating time between failures: scheduled run hours minus downtime, divided by failures. Availability is uptime over scheduled time. These are the standard repairable-system definitions. MTBF is only a mean: it hides whether failures are random, early-life or wear-out, which needs a Weibull analysis.

Reading the results

Look first at downtime hours, which combines frequency and repair time. A high failure count with a low MTTR points to a reliability problem such as repeated minor stops, so look at root causes. A low count with a high MTTR points to a repairability or spares problem. Compare MTTR to your logistics: if repair time includes waiting for parts, split that out because it measures the storeroom, not the technician.

Data quality traps

Breakdown start times entered when the technician arrives instead of when the machine stopped will understate MTTR. Work orders reopened later, or one failure recorded as three work orders, inflate the failure count. Check a sample of rows against the shift log. Also decide whether short stops under a few minutes belong in the analysis, and apply the same rule to every asset.

Frequently Asked Questions

What is the difference between MTBF and MTTR?

MTBF is the average operating time between failures and describes reliability. MTTR is the average time to restore the asset after a failure and describes maintainability. Availability combines them: MTBF divided by the sum of MTBF and MTTR.

Does this need an internet connection?

No. The script runs locally with Python and pandas, and the generator itself runs in your browser. Your failure data never leaves your computer unless you choose to share it.

Why are some assets missing from the output?

Assets with no failures in the period or with rows removed by the filters do not appear, because MTBF cannot be computed without at least one failure. Check the period dates and whether end times are missing or earlier than start times.

Can I get MTBF per failure mode?

Yes. Add a failure code column to your export and change the groupby to use the asset and the code together. Be careful with small samples: an MTBF built from two or three events says little.

We can connect this kind of analysis directly to your ERP maintenance history on-premises, so that the numbers refresh without CSV exports.