Overview
The Operations tile in the Mobaro Mobile App is the on-the-ground command center for ride and asset state. From it, operators open Locations at the start of the day, close them at the end, register Downtime as it happens, return a Location to operation once the issue clears, and watch live operational metrics throughout the shift. This article covers every action available from the Operations tile, explains the state model that drives those actions, and shows where the resulting data ends up.
Users must be Super Users or have the following Role to manage uptime and Downtime of a Location in the mobile app:
Locations: direct or indirect access to the Location
Why this matters: every state change you make from the Operations tile becomes part of your operational record. The same data feeds the Uptime Summary on the Locations page, Downtime widgets on Dashboards, Downtime and operational reports, and the Operational Log for audit. Accurate, real-time state changes from the floor are what keep the rest of Mobaro useful.
The operational state model
Before walking through actions, it helps to understand that Mobaro tracks three independent attributes per Location. Together they describe what the Location is doing right now and whether anyone is allowed to operate it.
Attribute | Possible values | What it means |
Ready for Operation | Ready / Not Ready | Whether the Location is currently allowed to be opened. Aggregates outstanding CFO Checklists, unresolved high-priority Assignments, active Blocking Downtimes, and other gating conditions. |
Operational status | Open / Closed | Whether the Location is currently running. |
Downtime status | None / Open / Blocking | Whether an active Downtime registration is in place, and whether it blocks reopening. |
Ready for Operation
Ready for Operation is the Location's aggregate readiness state — the green or red indicator on the left of each Location row. A Location stays Not Ready while any of these gating conditions are true:
One or more outstanding CFO Checklists for the day. Critical for Operation (CFO) is a flag set on individual Checklists and Schedules, marking them as required before the Location can open.
One or more unresolved high-priority Assignments on the Location.
An active Blocking Downtime.
Other gating conditions configured for your account.
Once every gating condition clears, the Location turns Ready and the open toggle becomes active. Tapping into a Not Ready Location shows which condition is currently holding it Not Ready, so you can clear it.
Note: A Location can be Closed without an active Downtime — for example, before opening hours start, or after closing for the day. Downtime specifically describes an unplanned interruption to operation while the Location is otherwise expected to be running.
What the Operations tile shows
The Operations tile surfaces live operational data for every Location you have access to that has Operational Logging enabled. The metrics give floor staff and supervisors an at-a-glance view of how the day is going without leaving the app — they're the same metrics that aggregate up to Dashboards in the Backend.
Icon | Metric | Use it for |
 | % daily uptime (and total time) | Quick read on how operationally healthy the day has been so far. |
 | % daily Downtime (and total time) | Spot Locations dragging on overall uptime targets and decide where to focus. |
 | Daily throughput (and % of guest-carry target) | Track ride capacity against your daily plan; surface underperforming Locations early. |
 | Daily dispatches (and % of dispatch target) | Spot operational efficiency issues — dispatches dragging suggests load times or staffing gaps. |
 | Total daily Downtime registrations | Pattern signal: many short Downtimes can hint at recurring issues worth investigating. |
 | Average daily queue time (and latest reading) | Guest-experience proxy; rapidly rising queues warn that capacity isn't keeping up. |
 | Number of attendants working | Confirms current staffing matches what RideOps expects for the Location. |
Reading the tile color ring
The colorization around the Operations tile aggregates the status of all Locations with Operational Logging enabled that you have access to:
Green | Locations marked as in operation. |
Red | Locations with an active Downtime — Open and Blocking both count. |
Grey | Locations marked as out of operation or closed. |
Opening and closing a Location
Tapping into the Operations tile shows the list of Locations you have access to. Each row shows:
Ready for Operation — Ready or Not Ready
Operational status — open or closed
Downtime status — none, open, or blocking
Time spent in the current status (hours and minutes)
For example, the Aerial Spin Carousel is Not ready for operation (Red Not Ready) and closed (Grey Not Operating):
The Galaxy Coaster below is Ready for Operation (Green Ready) and closed (Not Operating):
The Ferris Wheel Fiesta Balloon below is Ready for Operation (green) and open (Operating):
To open a Location
1. Confirm Ready for Operation
Check the indicator on the left of the Location row. If it's red (Not Ready), tap into the Location to see which gating condition is holding it Not Ready — outstanding CFO Checklists, an unresolved high-priority Assignment, an active Blocking Downtime, etc. — and clear it first.
2. Toggle the Location open
Once the indicator is green, tap the toggle on the right side of the Location row. The status turns green and the daily uptime clock starts.
Critical: Opening a Location requires Ready for Operation status. The indicator aggregates outstanding CFO Checklists, unresolved high-priority Assignments, and active Blocking Downtimes — any of which holds the Location Not Ready until it's cleared.
To close a Location
At the end of the day (or whenever the Location should stop running for non-Downtime reasons — weather closure, scheduled maintenance window, end of season, etc.), tap the toggle to closed. Closing a Location does not create a Downtime registration; it just ends the operational period for the day.
Registering a Downtime
Use Downtime registration when an open Location needs to stop running unexpectedly — a mechanical fault, a guest incident, weather pause, or any unplanned interruption that should be recorded against the day's uptime.
To start a Downtime:
1. Open the Location
Tap the Location name in the Operations tile.
2. Describe the Downtime
Enter a description of what happened — clear, factual, and specific enough that someone reading it later understands the situation.
3. Categorize the Downtime
Select the relevant Downtime category (e.g., Mechanical, Weather, Guest Incident). Categories drive how the Downtime appears in Reports and on Dashboards.
4. Add attachments
Add photos, videos, or documents that support the registration — fault indicator readouts, photos of the issue, witness statements, etc.
5. Save the Downtime
Tap Save. The Location's row in the Operations tile turns red, and the status indicator switches to show the Downtime type.
Open Downtime vs. Blocking Downtime
Whether a new Downtime is Open or Blocking depends on your account's Configuration > Downtime settings (specifically, whether the chosen Downtime category auto-generates a related work Assignment).
Type | Behavior | Best for |
Open | Created without a related Assignment. The Location can be reopened at any time without resolving anything else first. | Quick interruptions that don't need a work order — short weather pauses, brief guest incidents, etc. |
Blocking | Created with an automatically generated Assignment. The Assignment must be resolved before the Location can be marked back in operation. | Mechanical or safety issues that require maintenance to inspect, fix, and sign off before the Location can run again. |
Open Downtime on the Operations tile
Blocking Downtime on the Operations tile
Best practice: Configure your Downtime Templates so that mechanical and safety-critical categories generate Blocking Assignments, while non-mechanical interruptions (weather, queues, etc.) create Open Downtimes. This keeps the maintenance team's work queue focused on actual safety issues without forcing every short pause through the Assignment workflow.
Required: Toggling auto-Assignment behavior on or off, or changing which Templates trigger it, requires:
Organization: Administrate
Returning a Location to operation
When the issue that caused a Downtime is resolved, the Location can be returned to operation. The exact steps depend on whether the Downtime is Open or Blocking.
For an Open Downtime
1. Tap the Location row
From the Operations tile, tap into the Location showing the active Open Downtime.
2. Toggle the Location open
Tap the toggle to return to operation. The Open Downtime ends and the Location's row turns green.
For a Blocking Downtime
1. Resolve the related Assignment
A Blocking Downtime is tied to an automatically generated work Assignment. The user qualified to complete that Assignment (typically maintenance) must open it, perform the work, and submit the Result. Until that's done, the Location toggle stays disabled.
2. Toggle the Location open
Once the Assignment is resolved, the Blocking Downtime clears. With no other gating conditions outstanding, the Location's Ready for Operation indicator goes green and the toggle becomes active. Tap to return to operation.
Note: The duration of the Downtime — from registration to return to operation — is what counts against the day's Downtime metric. The clock keeps running until the Location is toggled back open, including any time spent waiting for maintenance to start the Assignment.
Limiting who can change operational state
Accurate uptime and Downtime data depends on the right people changing operational state — not just anyone with Location access. You can restrict that capability to specific User Groups.
Required: To configure this restriction, you need:
Organization: Administrate
To limit access:
1. Open Configuration
In the Mobaro Backend, navigate to Configuration.
2. Open the Locations tab
Click the Locations tab.
3. Enable the restriction
Check Limit location operational state management to (user groups).
4. Add User Groups
Add the User Groups whose members should be allowed to change operational state.
Note: If your organization uses RideOps, Users on a Location's Operators list are automatically allowed to change operational state — they don't need to be added to a User Group here.
Where your Downtime data shows up
Every action you take in the Operations tile feeds the rest of Mobaro within seconds (or queues for upload if you're offline). The same data shows up in five places:
Operations tile metrics — live percentages and counters update as you work.
Uptime Summary on the Locations page in the Backend — per-Location rollup of the day's uptime, Downtime entries, and durations.
Dashboard widgets — Downtime, uptime, and throughput widgets pull from the same data and can be filtered by Location, Location Group, Downtime category, and date range.
Reports — Downtime Reports and operational Reports break down Downtime by category, Location, time, and other dimensions for retrospective analysis.
Operational Log — chronological audit trail of every state change with the User who made it.
Example: a coaster's day with one mid-morning Downtime
Scenario
A roller coaster opens at 10:00 AM. At 11:24 AM an operator reports a brake-system warning. The maintenance team inspects, replaces a sensor, and signs off. The coaster reopens at 12:08 PM and runs through close at 9:00 PM.
Setup
At 9:30 AM, the lead operator completes the morning CFO Checklist on the mobile app — the only outstanding gating condition for opening. The coaster turns Ready for Operation.
At 10:00 AM, the operator taps into the Operations tile and toggles the coaster open. Daily uptime clock starts.
At 11:24 AM, the brake warning appears. The operator opens the Operations tile, taps the coaster, registers a Downtime in the Mechanical — brake fault category, attaches a photo of the warning indicator, and saves. Because Mechanical is configured as a Blocking category, an Assignment is auto-generated for the maintenance team. The coaster's row turns red.
Maintenance picks up the Assignment, performs the inspection, replaces the sensor, and submits the Assignment Result. The Blocking Downtime clears.
At 12:08 PM, the operator toggles the coaster back open. Daily uptime clock resumes.
At 9:00 PM, end of day, the operator toggles the coaster closed.
Result
Operations tile shows ~93% uptime for the day, with one Downtime entry, total Downtime ~44 minutes.
Uptime Summary on the Locations page shows the same numbers, with the Downtime entry expandable to see description, photo, category, and the resolved Assignment.
A Mechanical Downtime widget on the Park Director's Dashboard ticks up by one entry; the day's mechanical Downtime minutes update.
The Downtime Report for the week now includes this entry tagged as Mechanical — brake fault.
The Operational Log shows the open, the Downtime registration, the Assignment resolution, the reopen, and the close — with the User and timestamp on each.
Frequently asked questions
Q: Why don't I see the Operations tile on my app?
A: Three things can hide it: (1) you don't have access to any Location with Operational Logging enabled, (2) Operational Logging isn't enabled on any Location at all, or (3) your Mobaro app needs an update. Check those in order.
Q: Why can't I open a Location?
A: A Location can only be opened when its Ready for Operation indicator is green. Common reasons it isn't: outstanding CFO Checklists, an unresolved high-priority Assignment, or an active Blocking Downtime. Tap into the Location to see exactly what's holding it Not Ready. If your organization also restricts state management to specific User Groups, you need to be in one of them — or on the Operators list if RideOps is enabled.
Q: What's the difference between an Open Downtime and a Blocking Downtime?
A: Open Downtimes have no related Assignment — anyone authorized can reopen the Location whenever the issue clears. Blocking Downtimes are tied to a work Assignment, and the Location stays closed until that Assignment is resolved. Whether new Downtimes default to one or the other depends on the Downtime category and your Configuration > Downtime settings.
Q: How do I end a Downtime?
A: Toggle the Location back open. For an Open Downtime that's all that's needed. For a Blocking Downtime, the related Assignment must be resolved first — once that's done the toggle becomes active.
Q: Can I edit a Downtime after I've started it?
A: Yes — Administrators can edit Downtime entries from the Mobaro Backend via the Uptime Summary on the Locations page to correct details, add notes, or attach further evidence after the fact.
Q: My Location closed itself overnight. What happened?
A: It didn't — Locations only change state when a User toggles them. If a Location went from open to closed without a deliberate toggle, check the Operational Log to see who made the change and when.
Q: Does Downtime registered in the mobile app sync if I'm offline?
A: Yes. The Mobaro app captures Downtime registrations locally and syncs them when the device reconnects. The original timestamp of the registration is preserved, so the daily metrics reflect the actual time the issue occurred — not the time the device came back online.