Overview
MTTR (Mean Time To Repair) and MTBF (Mean Time Between Failures) are the two reliability metrics Mobaro calculates from your Downtimes and uptime. MTTR answers "when something breaks, how much operating time does it cost?"; MTBF answers "how long do we run between breakdowns?"
Both appear in the Location MTTR MTBF Dashboard widget. This article explains how each is calculated, how to read and filter them, and the habits that keep them trustworthy. For the widget's place on the Dashboard, see Downtime on Dashboards — color states and metric widgets.
At a glance |
|
Who can do this | Anyone who can view the Dashboard. The figures only include Locations you can see. |
Where | Dashboard › Location MTTR MTBF widget |
Works on | Backend (web) |
Availability | All organizations. Locations need Enable Operational Logging. |
💡 Why this matters: A team that fixes things fast (low MTTR) but breaks down often (low MTBF) is firefighting. A team with rare breakdowns but slow recovery has a response problem. Together the two metrics tell you whether to invest in prevention or in response.
MTTR — mean time to repair
Definition: the average recorded duration of the Downtimes that started in the selected period — their total duration divided by their number. The widget shows hours, so 0.75 means 45 minutes.
A Downtime's duration is the Actual Downtime confirmed when someone closes it in the Backend (or through the Public API), and can be edited later. If the Location has opening hours, the suggested duration only counts time inside them — see How opening hours affect downtime tracking. So MTTR measures operating time lost per Downtime as recorded, not the time from the fault to the fix on the clock.
⚠️ Heads-up: Downtimes that haven't been closed have no duration, but they still count in the number of Downtimes. Until you close them, they pull MTTR down. Close resolved Downtimes promptly.
How to read it:
Low MTTR: Downtimes cost little operating time. Could mean a strong process, parts on hand or trivial issues — check which.
High MTTR: fixes take a while. Common causes are parts on backorder, expertise held by a few people, or a root cause that isn't understood.
MTTR is sensitive to outliers: one two-week Downtime waiting for a part skews the average. Look at the Downtime list for the period before drawing conclusions, and don't delete a real Downtime to improve the figure.
MTBF — mean time between failures
Definition: the time the Locations were open (uptime) in the selected period, divided by the number of Downtimes that started in it. Time a Location was closed doesn't count, so MTBF measures reliability while running. Only uptime periods that have ended are counted: while a Location is open, its current period isn't included until it closes. Higher is better. The widget shows hours.
How to read it:
High MTBF: long stretches without a Downtime — reliable equipment, good preventive maintenance, or both.
Low MTBF: frequent Downtimes — ageing equipment, missed maintenance or operating issues. Investigate the root cause.
Falling over months: something is degrading. Often the early warning before a major failure.
MTBF depends on accurate uptime and consistent Downtime registration. If Locations are left open by mistake, correct the periods — see Reviewing and correcting uptime in the Uptime Summary. If your team only registers blocking failures, MTBF looks better than it is.
Filter the widget
The Location MTTR MTBF widget has three filters:
Time range: a preset such as Last week or Current month, a number of days, weeks or months, a specific month, or a Custom Time Range. A Downtime counts in the period it started.
Category: count only Downtimes with the selected Downtime categories. MTBF still uses all uptime, so it becomes the time between failures of that kind.
Locations: pick Locations or Location Groups.
Click MTTR or MTBF to open the details: a table per Location with Downtime Count, Downtime, Uptime, MTTR and MTBF, which you can sort. Each widget shows one period; to compare two periods, add the widget twice with different time ranges.
Worked examples
Example 1: A coaster's MTBF dropping
Scenario: a coaster's MTBF has fallen from about 120 hours in spring to about 40 in summer, through a string of minor Downtimes.
Setup: filter the widget to that Location for the last 90 days, then add a copy filtered to the Mechanical — restraints Downtime category.
Result: most of the drop comes from restraint issues. The team starts a focused maintenance campaign on the restraints before a blocking failure on a peak day.
Example 2: High MTTR in one area
Scenario: an area's MTTR is about twice that of a neighbouring area with similar rides.
Setup: filter the widget to the area's Location Group for the last 30 days and click MTTR to see the details.
Result: two Locations, where every Downtime takes over three hours, drive the average. Both depend on a part stocked only at the central warehouse. Stocking it locally roughly halves the area's MTTR.
Example 3: Comparing seasons
Scenario: leadership wants to know whether reliability of the premium rides improved year on year.
Setup: two copies of the widget, both filtered to the premium rides' Location Group — one for this season, one for last season.
Result: MTBF is up 18% and MTTR is flat: fewer breakdowns, same recovery time.
Common pitfalls
Unclosed Downtimes: they count with no duration and pull MTTR down.
Inconsistent registration: if some Operators log every short stop and others only blocking failures, neither metric is meaningful in aggregate. Agree what gets registered.
Watching MTTR alone: an MTTR of 30 minutes looks great until MTBF is 8 hours.
Small samples: three Downtimes in 90 days give noisy figures. Use longer periods.
Confusing MTBF with availability: MTBF is hours between failures; availability is uptime as a percentage — see Uptime, downtime, and lag time explained.
Best practices
Close resolved Downtimes promptly and check the Actual Downtime before you confirm it.
Use Downtime categories consistently, so the category filter is meaningful.
Open and close Locations when they really start and stop; MTBF is only as good as your uptime.
Compare like with like: the same Locations, same categories and periods of similar length.
Frequently asked questions
What does MTTR stand for?
Mean Time To Repair: the average recorded duration of the Downtimes that started in the period. Its partner, MTBF (Mean Time Between Failures), is the uptime in the period divided by the number of Downtimes.
Recorded downtime isn't showing in MTTR and MTBF. Why?
Check that the Downtime is closed; until then it counts with no duration. Then check the widget's time range (Downtimes count by start time), its category filter and its Locations. The widget only includes Locations you can see.
How are non-blocking downtimes handled in MTTR?
The same as blocking ones. MTTR averages the recorded duration of every Downtime that started in the period, whatever its state. Downtimes that aren't closed yet count with no duration. See Using downtime in Mobaro.
Can I export MTTR and MTBF data?
No. The widget and its details table have no export. For your own analysis, pull Downtimes and uptime periods through the Public API. See Getting started with the Mobaro API.