Overview
Downtime records when a Location is unexpectedly out of operation, captures the cause, and (optionally) drives the work needed to get it running again. It's a system that touches a lot of Mobaro — Locations, RideOps, Configuration, and Dashboards — so this article is the map: the lifecycle of a downtime and where each part is documented.
Users must be Super Users or have the following to manage Downtime:
Operations: Manage Downtime, plus access to the relevant Locations
Why this matters: Downtime is only useful if it's captured consistently and measured against the time a Location should actually have been running. Done well, it turns scattered "the ride was down" moments into reliable uptime figures, reliability metrics, and a maintenance trail.
The downtime lifecycle
A downtime moves through three stages:
Stage | What it means |
Active (Open or Blocking) | The Location is out of operation. An Open downtime has no linked work; a Blocking downtime has an open Assignment that must be resolved before the Location can reopen. |
Resolved | The Location has been returned to operation. The interruption is over, but the entry isn't yet finalized for reporting. |
Closed | An admin has finalized the measured duration in the Backend. Only closed downtimes count in historical reporting. |
Note: A Blocking downtime keeps the Location from reopening until its linked Assignment is resolved. The full state model and how operators move a downtime through it live in Managing Downtime and uptime from the mobile app.
How downtime fits across Mobaro
Step | Where it happens |
Set it up | Enable operational logging, create categories, and configure auto-Assignment. See Getting started with Downtime. |
Log it | From the mobile app or RideOps, on the floor. See Managing Downtime and uptime from the mobile app and downtime templates for RideOps. |
Measure it | Against the Location's operating hours. See How downtime is measured and operating hours. |
Review it | On the Location's Uptime Summary in the Backend. See Reviewing downtime on the Locations page. |
Report on it | On Dashboards and reliability metrics. See Downtime on Dashboards and MTTR and MTBF. |
Key concepts
Open vs Blocking — whether a downtime auto-creates an Assignment that gates reopening. Set globally or per downtime template.
Categories — the admin-defined causes applied to a downtime, driving how it appears in reports and on Dashboards.
Uptime, downtime, and lag time — the related operational-time metrics. See Uptime, downtime, and lag time explained.
Frequently asked questions
Q: What makes a downtime "blocking"?
A: An open Assignment attached to it. Blocking downtimes keep the Location from reopening until that Assignment is resolved; whether one is created depends on your global setting or the downtime template.
Q: Why does a downtime still show after the Location is back in operation?
A: It's resolved but not yet closed. Closing it in the Backend finalizes the measured duration — and only closed downtimes count in reporting. See Reviewing downtime on the Locations page.
Q: Can a downtime exist without an Assignment?
A: Yes — that's an Open downtime. Assignments are optional and depend on your configuration and the downtime template used.