Overview
Downtime is logged on the floor — from the mobile app or RideOps — but it's reviewed and finalized in the Mobaro Backend, on the Location's Uptime Summary. This is where an admin sees a Location's operating periods and downtime history, corrects entries, closes a downtime to finalize its measured duration, and logs a past downtime that was missed in the moment. This article covers all of that.
Users must be Super Users or have the following to review and edit downtime here:
Operations: Manage Downtime, and Locations: View or Modify
Why this matters: Floor staff capture downtime quickly, but the numbers that feed your reports and Dashboards are finalized here. The Uptime Summary is where you make sure the recorded duration reflects the time the Location should actually have been operating — see How downtime is measured.
What the Uptime Summary shows
Open a Location from the Locations page in the Backend and find its Uptime Summary. It presents the Location's operational timeline:
Operating periods — when the Location was open and closed (the operational log).
Downtime entries — each registration with its description, category, attachments, state, and duration.
Uptime and downtime totals — the rolled-up figures for the period you're viewing.
Review and correct downtime
Find the downtime
In the Uptime Summary (or the Downtime section), locate the entry. To see finalized entries, make sure your state filter includes Closed.
Edit the details
Open the entry and adjust its description, category, times, or attachments. Corrections here flow through to reports and Dashboards.
Note: Even Closed downtimes can be edited — useful for adding evidence or fixing a category after the fact. The change is reflected in historical reporting.
Close a downtime to finalize it
A downtime only counts in historical reporting once it's closed. When you close one, Mobaro suggests a duration based on when it started and when the Location returned to operation — adjust it so it reflects only the time the Location should have been running, then confirm.
Best practice: Close downtimes promptly. Open or resolved-but-not-closed entries aren't yet in your historical figures, so a backlog of unclosed downtimes makes reports understate reality.
Log a past downtime
If a downtime wasn't captured when it happened, you can add it after the fact. Create a downtime against the Location within the relevant operating period, setting its start and end times, category, and description — and, if follow-up work is needed, an Assignment. It's recorded just like a live downtime, with the times you specify.
Note: Set the start and end to the real times the interruption occurred, not when you're entering it — the measured duration and your reports depend on it.
Where this data goes
Everything finalized here feeds the rest of Mobaro: live figures on the Operations tile, the downtime and reliability widgets on Dashboards, and downtime reports and exports.
Frequently asked questions
Q: I closed a downtime but the duration looks wrong.
A: Re-open the entry from the Uptime Summary (include Closed in the state filter) and edit the times. Only count time the Location should have been operating — see How downtime is measured.
Q: Why isn't a downtime showing in my report?
A: It may not be closed yet. Only closed downtimes count in historical reporting.
Q: Can I add a downtime for something that happened last week?
A: Yes — log a past downtime with the real start and end times. It's recorded against that operating period as if it had been captured live.