Overview
Mobaro tracks how operationally healthy a Location is through three related time metrics: uptime, downtime, and — for RideOps — lag time. They're easy to confuse, so this article defines each, shows how they fit together, and points to where they surface across Mobaro.
Why this matters: These three numbers answer different operational questions — "was the ride running?", "how much did we lose, and why?", and "how fast did we recover once it was fixed?". Reading them together is how you tell a reliability problem from a response problem.
The three metrics
Metric | What it measures |
Uptime | The time a Location was actually open and operating, against the time it was expected to run. Usually read as a percentage of the operating day. |
Downtime | Time the Location was unexpectedly out of operation when it should have been running, captured as Downtime registrations with a cause (category). |
Lag time (RideOps) | The gap between maintenance marking an issue resolved and operations resuming dispatch — how long recovery took after the fix was done. |
Uptime
Uptime is the share of expected operating time a Location was actually running. It's the headline "how did the day go?" number, shown as a percentage on the Operations tile and rolled up on Dashboards. Uptime and downtime are two sides of the same operating day: time the Location should have been running is either uptime or downtime.
Note: "Expected operating time" comes from the Location's opening hours. Without them, Mobaro measures against a full day — see How operating hours affect downtime tracking.
Downtime
Downtime is an unplanned interruption while a Location is expected to be running — a fault, an incident, a weather pause. Each is recorded as a Downtime registration with a category, and its measured duration counts against the day once it's closed. Closing a Location for the night or for planned maintenance is not downtime. For how the duration is measured, see How downtime is measured.
Lag time (RideOps)
Lag time is a RideOps measure of operational responsiveness. The clock starts when maintenance marks the issue resolved and stops when operations resumes dispatch on the Ride Panel. It isolates the recovery gap that isn't about the repair itself — the time between "it's fixed" and "we're running again".
Lag time example: Maintenance clears the issue at 12:15 PM; operations dispatches again at 12:40 PM → lag time is 25 minutes.
Best practice: Watch lag time alongside downtime. High downtime with low lag time points to reliability (things break); low downtime with high lag time points to response (slow to restart after a fix). They call for different fixes.
Where these surface
Operations tile (mobile app) — live uptime and downtime percentages per Location. See Managing Downtime and uptime from the mobile app.
Uptime Summary (Locations page) — the per-Location history of operating periods and downtime. See Reviewing downtime on the Locations page.
Dashboards — downtime, uptime, and reliability widgets. See Downtime on Dashboards and MTTR and MTBF.
Frequently asked questions
Q: Is closing a Location at night counted as downtime?
A: No. Downtime is unexpected interruption during expected operating time. Planned closures and out-of-hours time aren't downtime.
Q: Is lag time available outside RideOps?
A: Lag time is a RideOps measure — it depends on the maintenance-resolved and dispatch-resumed signals that RideOps captures.
Q: Do uptime and downtime always add up to the operating day?
A: Across expected operating time, broadly yes — running time is uptime, unexpected stoppage is downtime. Out-of-hours time is neither.