Overview
Mobaro records three operational-time figures for every Location with Enable Operational Logging: uptime, downtime and lag time. They're easy to confuse, so this article defines each one, explains how Mobaro calculates it and shows where you see it.
For how a Downtime is started, closed and corrected, see Using downtime in Mobaro.
At a glance |
|
Who can do this | Anyone with access to the Location. The app and Dashboards only include Locations you can see. |
Where | Mobile app › Operations tile; Dashboards › Location Operational History, Operational History Details and Ride Operations Timeline widgets |
Works on | Backend (web), Mobile app. Uptime periods and Downtimes are also in the Public API. |
Availability | All organizations. The Location needs Enable Operational Logging. |
💡 Why this matters: The three figures answer different questions: was the ride running, how much time did faults cost, and how quickly did it reopen once the Downtime was over? Reading them together tells a reliability problem from a response problem.
The three metrics
Metric | What it measures | Recorded from |
Uptime | Time the Location was open (in operation) | Uptime periods: from each opening to the next closing |
Downtime | Time lost to unexpected stops | Downtime registrations and their confirmed duration |
Lag time | Time the Location stayed closed after a Downtime before it was opened again | The gap between uptime periods around a Downtime |
Uptime
Uptime is recorded, not predicted. An uptime period starts when someone opens the Location — in the Mobaro app, RideOps, the Backend or through the Public API — and ends when it's closed or a Downtime starts. Mobaro never opens or closes a Location by itself, and opening hours don't create uptime.
If a Location was opened by mistake, that time counts as uptime until you correct it. Edit or delete the wrong periods in the Location's Uptime Summary — see Reviewing and correcting uptime in the Uptime Summary.
Downtime
A Downtime is an unexpected stop, such as a fault, an incident or a weather pause. It's recorded with a start time and categories, and gets its confirmed duration when someone closes it in the Backend. Closing a Location at the end of the day or for planned work isn't downtime and doesn't create one.
When a Location has opening hours, the duration Mobaro suggests when you close a Downtime only counts time inside them. That suggestion is the only thing opening hours affect — see How opening hours affect downtime tracking.
How the percentages are calculated
Mobaro doesn't measure uptime against opening hours or a full day. The percentages compare the recorded figures with each other:
Operations tile in the app: the Uptime percentage is uptime ÷ (uptime + downtime) so far today. A Downtime that isn't closed yet counts its running time from start to resolved, or to now.
Location Operational History and Operational History Details widgets: uptime ÷ (uptime + downtime + lag time) over the widget's time range. Only closed Downtimes count.
Time a Location was simply closed counts as neither uptime nor downtime. Because the two calculations differ, the app and a Dashboard can show different percentages for the same day.
Lag time
Lag time is how long a Location stayed out of operation after a Downtime before someone opened it again. Mobaro calculates it from the operational log, so it works for any Location with Operational Logging. It doesn't need RideOps and doesn't use dispatches or maintenance sign-off.
For each uptime period that ended in a Downtime, Mobaro takes the time from the end of that period to the next opening, and subtracts the Downtime's duration. For example, a ride goes down at 12:00, the Downtime is closed with a duration of 15 minutes, and the operator opens the ride at 12:40: lag time is 25 minutes.
⚠️ Heads-up: Lag time only includes Downtimes that are closed with a duration. When the duration is trimmed to opening hours, a Downtime that runs past closing time adds the closed hours overnight to lag time. Set a Lagtime Threshold to leave those out.
The Location Operational History and Operational History Details widgets have a Lagtime Threshold (in minutes) filter, set to 300 minutes by default: all lagtimes with a longer duration are excluded from the calculations. Operational History Details only shows its Lagtime column while a threshold is set. The Ride Operations Timeline shows the gap between a Downtime and the next opening as Recovery Lag, marked Exceeds lag time threshold when it's longer than the threshold.
Where you see them
Operations tile (Mobile app): each Location's Uptime and Downtime percentages for the day. See Managing Downtime and uptime from the mobile app.
Uptime Summary (Backend, Locations page): the individual uptime periods. See Reviewing and correcting uptime in the Uptime Summary.
Location Operational History and Operational History Details widgets: uptime, downtime and lag time per Location. See Location Operational History Widget and Operational History Details Widget.
Ride Operations Timeline widget: each day as In Operation, Downtime, Recovery Lag and Out of Operation. See Ride Operations Timeline Widget.
Reliability: MTTR and MTBF and Downtime on Dashboards.
Best practices
Open and close Locations when they really start and stop. Uptime is only as accurate as those actions.
Close Downtimes promptly with an accurate duration. Unclosed Downtimes don't count in the history widgets or in lag time.
Keep a Lagtime Threshold set, so overnight gaps don't swamp lag time.
Read downtime and lag time together: high downtime with low lag time points to reliability; high lag time points to a slow restart after the fix.
Frequently asked questions
What's lagtime?
The time a Location stayed closed after a Downtime before someone opened it again: the gap between the uptime period that ended in the Downtime and the next opening, minus the Downtime's duration. It works for any Location with Operational Logging, not only RideOps.
How is uptime generated?
From opening and closing the Location. Each time someone opens it in the app, RideOps, the Backend or the Public API, an uptime period starts; closing it or starting a Downtime ends it. Opening hours and schedules don't create uptime.
A ride shows uptime for days it was closed. Why?
Someone opened it in Mobaro during that time, so uptime periods were recorded. Open the Location's Uptime Summary and fix the wrong periods with Edit Period or Delete Period; this needs Super User or Operations › Manage Downtime. See Reviewing and correcting uptime in the Uptime Summary.
How do I see downtime as a percentage?
Add the Location Operational History widget to a Dashboard and tick Show as Percentage, or use Operational History Details for each Location. Percentages are shares of uptime + downtime + lag time, not of opening hours. For downtime by cause, use Downtime by Category.
Can I track downtime against an asset?
No. A Downtime is always recorded against a Location. Describe the part that failed in the Downtime or in its Assignment. See Using downtime in Mobaro.