Overview
In the Mobaro app, the Operations tile is where operators open and close Locations, start Downtimes and follow each Location's live metrics during the shift.
At a glance |
|
Who can do this | Users with access to the Location. If Limit location operational state management to (user groups) is set, only members of those User Groups. |
Where | Mobaro app › Operations tile › a Location |
Works on | Mobile app (online only). Backend and RideOps have the same actions. |
Availability | All organizations. The Location needs Enable Operational Logging. |
💡 Why this matters: Every action here goes into the Location's operational record, so Mobaro's figures are only as accurate as the state changes made on the floor.
When the Operations tile appears
The Operations tile shows when at least one Location you can access has Enable Operational Logging on. If Limit location operational state management to (user groups) is set, you must also be in one of those User Groups, even as a Super User.
⚠️ Heads-up: The Operations tile needs a live connection: offline it's greyed out and nothing is queued. A Downtime starts when Mobaro receives it.
The operational state model
Mobaro tracks three things for each Location with Operational Logging:
Attribute | Values in the app | What it means |
Readiness | Ready / Not ready | Whether the Location can be opened (green or red). |
Operational status | Operating / Not operating | Whether the Location is open. |
Downtime status | None / Open downtime / Blocking downtime | Whether a Downtime is active, and whether it blocks reopening. |
A Location is Not ready while critical-for-operation Checklists or critical Assignments are outstanding, or during a Blocking Downtime if Red if a blocking downtime is active on the location is on. Which items count follows your header-colour settings; see Configuring readiness colors on the Location Overview.
What the Operations tile shows
The ring around the Operations tile sums up your accessible Locations with Operational Logging:
Colour | What it counts |
Green | Locations that are open (operating). |
Red | Locations with an active Downtime (Open or Blocking). |
Grey | Locations that are closed. |
Tap the tile to see your Locations. The card view shows each Location's live figures for the day:
Icon | Metric | Use it for |
 | Uptime (%) | How the day has gone so far. |
 | Downtime (%) | Spot Locations dragging down uptime. |
 | Guests (RideOps Locations) | Track guests carried against your plan. |
 | Dispatches (RideOps Locations) | Spot slow loading or staffing gaps. |
 | Number of Downtimes | Many short Downtimes can point to a recurring issue. |
 | Latest queue time (RideOps Locations) | Rising queues warn that capacity isn't keeping up. |
 | Staffed Positions (RideOps Locations) | Check that the ride's Positions are covered. |
Open or close a Location
Tap a Location to see its state and today's activities. The buttons at the bottom are Start Downtime and Open location or Close location.
For example, the Aerial Spin Carousel is Not ready and Not operating:
The Galaxy Coaster is Ready but Not operating:
The Ferris Wheel Fiesta Balloon is Ready and Operating:
1. Check that the Location is Ready
While a Location is Not ready, Open location is disabled. The detail view counts the critical Assignments, critical Checklists and Downtimes holding it; clear them first.
2. Tap Open location
Confirm to open. Mobaro may first warn that no maintenance Checklists are scheduled today, that there's an Open Downtime, or that the Location has a RideOps Preopening Checklist (Open anyway). These warnings don't stop you.
🛑 Critical: Read every warning before you confirm. The app can't check whether a RideOps Preopening Checklist was completed, and a Location with no maintenance Checklist scheduled today may not have been inspected. Verify manually first.
3. Tap Close location when you stop
At day's end or any planned stop, tap Close location and confirm. Closing doesn't create a Downtime. Mobaro never opens or closes a Location by itself.
Start a Downtime
Start a Downtime when a Location stops unexpectedly, such as a fault or weather pause. This closes an open Location.
1. Tap Start Downtime
Open the Location and tap Start Downtime.
2. Describe and categorize it
Enter a factual Description, pick Categories (your organization decides whether they're required and how many), and add photos.
3. Tap Start
The Location now shows Open downtime or Blocking downtime.
⚠️ Heads-up: Start Downtime is disabled while the Location is Not ready or already has an Open or Blocking Downtime (only one can be active). On a red Location, register the Downtime in the Backend or RideOps.
Open vs Blocking Downtime
A Downtime started in the app is Open unless Create an assignment when a new downtime is started is on in Configuration › Downtime. Then Mobaro creates an Assignment for the Assignment assignee (User Group) and the Downtime is Blocking. Categories don't change this: one setting covers every app Downtime.
Type | Behavior | Best for |
Open | No related Assignment. Opening the Location resolves the Downtime. | Short pauses that don't need a work order. |
Blocking | Has an automatic Assignment. The Location can't open until it's resolved. | Issues that maintenance must inspect and sign off. |
Downtime Templates can set their own assignment policy but apply only to RideOps Downtimes; see Creating downtime templates for use in RideOps. Downtimes started in the Backend never create an Assignment automatically.
An Open downtime in the Operations list:
A Blocking downtime in the Operations list:
Return a Location to operation
After an Open Downtime: tap the Location, tap Open location and confirm the open-downtime warning. This resolves the Downtime.
After a Blocking Downtime: resolve the related Assignment first (usually maintenance does). That resolves the Downtime so you can tap Open location. Closing the Downtime in the Backend also allows opening; the Assignment stays open.
Resolved Downtimes are later closed in the Backend (Downtime › Close Downtime), confirming the duration used for MTTR; see Downtime on Dashboards.
Limit who can change state
You can restrict these app actions to specific User Groups. This needs Super User or Organization › Administrate.
1. Open the Locations configuration
In the Backend, go to Configuration and open the Locations tab.
2. Choose the User Groups
Under Operational Settings, add the User Groups to Limit location operational state management to (user groups), then save. Only members of those groups see the Operations tile in the app.
Where your data shows up
Downtime list in the Backend: review, edit and close Downtimes (needs Operations › Manage Downtime).
Uptime Summary on the Locations page: the Location's uptime periods; see Reviewing downtime on the Locations page.
Dashboards: Location Overview status and MTTR/MTBF; see Downtime on Dashboards.
Operational Log: every opening, closing and Downtime with the user and time; see Log book in the Mobaro app.
Best practices
Turn on Create an assignment when a new downtime is started only if every app Downtime should wait for maintenance sign-off. If it depends on the cause, use RideOps Downtime Templates.
Start the Downtime as soon as the Location stops, with a factual description and photo.
Close Locations at the end of the day.
Close resolved Downtimes promptly in the Backend so durations and MTTR are accurate.
Frequently asked questions
Why don't I have the Operations tile in my app?
You need access to a Location with Enable Operational Logging on. If state management is limited to User Groups, you must be in one, even as a Super User. An App Area Availability Rules entry can also hide it. Offline, the tile is greyed out.
Why can't I open the ride even though the checklists are done?
Because the Location is still Not ready. Besides critical Checklists, critical Assignments and, depending on your settings, a Blocking Downtime can hold it red. Tap the Location to see what's outstanding. See Troubleshooting red statuses in location overviews.
Does a downtime assignment stop the ride from reopening?
Yes, if Mobaro created it automatically: that Downtime is Blocking, so the Location can't open until the Assignment is resolved. This depends on Create an assignment when a new downtime is started (app) or the Downtime Template (RideOps).
How do I resolve a downtime in the app?
For an Open Downtime, tap the Location, then Open location; opening resolves it. For a Blocking Downtime, resolve its Assignment first. You close a Downtime and confirm its duration in the Backend.
Can I edit a downtime after it's been logged?
Yes, in the Backend: Downtime › Edit Downtime, with Operations › Manage Downtime. The duration can only be changed once the Downtime is closed. To add a Downtime to a past period, see Reviewing downtime on the Locations page.
Will a location open or close automatically with our opening hours?
No. Only a person (in the app, RideOps or the Backend) or an integration opens or closes a Location. Opening hours affect how Downtime is counted, not the state; see How opening hours affect downtime tracking.