Use a season review to compare recorded operating time and interruptions across Locations. Start with the records behind the totals, then use consistent Dashboard filters for the comparison.

Recorded uptime is the time Mobaro has the Location open. It is not a dispatch count, rider total or a guarantee that the ride ran continuously throughout that period.

Choose exact season start and end dates, the reporting time zone and the Locations to include. Record any exclusions, such as a ride that opened partway through the season.

Use the same date range and Location scope on the widgets you compare. Check personal as well as organization filters. A viewer’s access can change which Locations appear; see Dashboard filters.

Open each relevant Location’s Uptime Summary and inspect unusual periods, such as a ride left open overnight. A missing open or close action can distort the season’s recorded hours. See reviewing and correcting uptime.

Review Open, Blocking and Resolved Downtimes with the responsible team. Close records only after confirming their actual duration and categories. Operational History Details counts closed Downtimes; unresolved record review can leave its totals incomplete.

Downtime duration may be calculated against configured opening hours or entered manually. Check the basis of unusual values before comparing them. Correct the operational record when justified; do not change records merely to make a seasonal total look better. See opening hours and Downtime.

Use Operational History Details for Location-level uptime and Downtime durations, percentages, Downtime count and optional lag time. Apply the same date range, Locations, category scope and lag-time threshold for each comparison.

Caption: Compare durations using the same reporting period, Locations and lag-time setting.

Alt text: Operational History Details widget crop with source-defined columns for Location, Uptime, Downtime, Downtimes and Lag Time, showing fictional figures.

Only ended uptime periods count, clipped to the selected range. A closed Downtime contributes its full confirmed duration when it started inside that range, so events crossing the season boundary need careful interpretation.

The percentages describe the time included in this calculation. They are not automatically percentages of every advertised opening hour. Category filters and lag-time choices can change the basis. Use the widget reference and uptime, Downtime and lag time to interpret them.

This widget has no built-in export button. Record the report date, season range, time zone, Location scope, filters and any known incomplete records alongside the figures. If the report needs a daily spreadsheet or recurring data feed, use the performance API reference and an authorized integration; agree the day boundaries and aggregation before building it.

After correcting a record, refresh the report and record that the figures changed. Use the review to identify interruptions worth investigating, then open the underlying Downtimes and linked Assignments before drawing conclusions about causes.

Can I export operational hours per Location for every day?

That needs daily aggregation. The Uptime Summary shows periods, and the widget totals its selected range. For a daily spreadsheet or feed, use an authorized integration with the performance API reference and verify date boundaries.

Can I review one ride’s uptime for a whole year?

Yes. Scope Operational History Details to that Location and the intended year. Check the underlying uptime periods and incomplete Downtime records before treating the result as final.

How do I export Downtime information?

First decide whether you need event records, totals or a recurring feed. Use the report selection guide and performance API reference for the matching route; verify closed-state and date filters.