Overview
MTTR (mean time to repair) and MTBF (mean time between failures) are the two reliability metrics Mobaro computes from your downtime registrations. Together they answer two different questions: "when something breaks, how long does it take us to fix it?" and "how often do things break in the first place?" Both surface in the Location MTTR/MTBF Dashboard widget; both depend on consistent downtime logging to be meaningful.
Why these matter: A maintenance team that's fast at fixes (low MTTR) but has lots of breakdowns (low MTBF) is firefighting. A team with rare breakdowns (high MTBF) but slow recovery (high MTTR) has a process problem. The metrics together tell you whether to invest in prevention or in response — they're complementary, not interchangeable.
MTTR — mean time to repair
Definition: The average elapsed time from when a downtime is registered until the Location is marked back in operation. Measured in fractional hours on the widget (so 1.5 = 90 minutes); click the widget for exact minute-level numbers.
What it measures: How fast your team can resolve a problem once it's been registered. Includes triage, parts retrieval, the actual fix, and verification. Does not include the time before the downtime was registered (i.e., it doesn't measure detection lag).
How to read it:
Low MTTR = your team is fast at fixes. Could mean strong process, well-stocked parts, or trivial issues. Worth checking which.
High MTTR = fixes are taking a while. Common causes: parts on backorder, expertise concentrated in a few people, root cause not understood (so the same issue recurs).
Caveat: MTTR is sensitive to outliers. One downtime that took two weeks because of a backordered part will skew the average significantly. Look at MTTR alongside the underlying downtime list before drawing conclusions.
MTBF — mean time between failures
Definition: The average operational hours between downtime registrations on a Location. Measured in operational hours — closed periods don't count.
What it measures: How often a Location experiences downtime when it's running. Higher is better.
How to read it:
High MTBF = the Location goes long stretches without breaking. Reliable equipment, good preventive maintenance, or both.
Low MTBF = frequent failures. Could be aging equipment, missing PM, or operator-induced issues. Worth investigating root cause.
Trending down over months = something is degrading. Often the leading indicator before a major failure.
Caveat: MTBF assumes you're consistently registering downtimes. If your team only registers blocking failures and ignores minor ones, MTBF will look better than it is. Whatever your registration practice, be consistent — comparing MTBF across periods only works if the registration bar hasn't moved.
Filtering the widget
The Location MTTR/MTBF widget supports several filter dimensions, each useful for a different lens on reliability:
Scope — all Locations, a Location Group, or a single Location.
Time period — last 7 days, last 30, last quarter, custom range.
Categories — if your downtimes are tagged by category (mechanical, electrical, operator-error, weather), you can isolate one category at a time.
The most useful filtering pattern is comparing the same Location across two time periods (last 30 days vs prior 30) to see whether reliability is improving or degrading — and then drilling into the Category breakdown to understand why.
Worked examples
Example 1: Coaster MTBF dropping over time
Scenario: A coaster's MTBF has dropped from ~120 operational hours (mid-spring) to ~40 (mid-summer). Maintenance hasn't seen any major failures, just a string of minor ones.
Setup: Filter the Location MTTR/MTBF widget to that Location, time period set to the last 90 days.
Result: The drop is visible. Filtering by Category shows the increase is concentrated in Mechanical — restraints. The team starts a focused PM campaign on the restraint system before the issues escalate to a blocking failure on a peak-attendance day.
Example 2: MTTR investigation across an area
Scenario: A maintenance lead notices their area's MTTR is roughly twice that of a neighboring area. Both areas have similar ride counts and similar age of equipment.
Setup: MTTR/MTBF widget scoped to the area's Location Group, last 30 days.
Result: Drilling in by Location shows MTTR is heavily skewed by two specific Locations where every downtime takes 3+ hours. Investigation reveals both rely on a part that's only stocked at the central warehouse, not the area shop. Pre-stocking the part locally cuts area MTTR roughly in half.
Example 3: Comparing reliability across operating seasons
Scenario: Operations leadership wants to know whether reliability has improved year-over-year for the park's premium attractions.
Setup: MTTR/MTBF widget scoped to the premium ride Location Group, with two time-period comparisons (current operating season vs prior).
Result: MTBF is up 18%, MTTR is flat. Reliability investments have paid off in fewer breakdowns; recovery time hasn't changed materially. Leadership uses the data to justify continued PM investment.
Anti-patterns to avoid
Watch out for these patterns, which produce misleading numbers:
Inconsistent downtime registration — if some operators log every minor blip and others only log blocking failures, neither MTTR nor MTBF is meaningful in aggregate. Standardize the registration bar across the team.
Treating MTTR as the only metric — a team with MTTR = 30 min looks great until you notice MTBF = 8 hours. Fast fixes don't compensate for frequent breakdowns.
Comparing MTBF across time periods with different operating cadences — MTBF uses operational hours, but if your registration practices changed between periods, you're comparing apples to oranges.
Drawing conclusions from small samples — a Location with 3 downtimes in 90 days produces noisy MTTR/MTBF numbers. Look at trends over longer windows for these.
Confusing MTBF with availability — MTBF is hours-between-failures. Availability is uptime as a percentage. They're related but not the same; both have their place.
See also
Downtime on Dashboards — color states and metric widgets — for the visual indicators on Location cards and the MTTR/MTBF widget.
Downtime registration overview — for the lifecycle of a downtime registration.
Frequently asked questions
Q: Does MTTR include the detection lag (time between failure occurring and being registered)?
A: No. MTTR starts at downtime registration. If detection is lagging, that's a separate process problem worth tracking outside MTTR.
Q: Why does the widget show 0.75 instead of 45 min?
A: Mobaro displays MTTR in fractional hours on the widget face for compact display. Click into the widget for the exact minute-level breakdown per Location.
Q: How are non-blocking downtimes handled in MTTR?
A: They count from registration to resolution, same as blocking downtimes. The metric measures resolution time, not the operational impact.
Q: Can I export MTTR/MTBF data for outside analysis?
A: Click into the widget for the per-Location breakdown, which can be exported. For deeper analysis, the underlying downtime data is available through the Mobaro API.
Q: We had a single 14-day downtime that's destroying our MTTR. Can we exclude it?
A: Not from the widget itself — it shows the average over the time period. To work around: shorten the time period to exclude the outlier, or use the underlying data with the API to compute MTTR with that record removed. Do not delete the downtime registration; that erases the audit record.