At a glance
Track interruptions that take a location out of operation and report the impact.
Understand the four downtime states (open → blocking → resolved → closed).
Optionally link downtime to assignments to manage corrective actions.
Who this is for
Admins / super users configuring and reporting on downtime
Operations / maintenance leaders who need consistent downtime workflows and follow-up
Frontline users recording downtime from the mobile app
Prerequisites
To manage downtime, users must be super users or have the role permission Operations: Manage downtime.
A location must have Operational logging enabled to track uptime/downtime consistently.
Overview
Downtime helps you record when a location is out of operation, understand what caused the interruption, and (optionally) track the work needed to restore operations using assignments.
Why use downtime?
Downtime reporting typically supports three outcomes:
Downtime registration: capture what happened and when it started.
Operational hours impact: understand lost operational time based on your logged operating periods.
Assignment management: track corrective actions tied to the downtime incident.
Navigation paths
In the mobile app
Use the Operations tile to open/close locations and register downtime.
In the web app
Use the locations workflow to review and correct operational logs and downtime periods (including adding a downtime into an existing uptime period).
In the RideOps app
Use the Start a Downtime button to create a downtime for a location.
How downtime states work
Each downtime registration moves through a state based on where it is in the workflow.
State | What it means | What typically moves it forward |
Open | A downtime has been created (mobile, web, or RideOps). | Mark the downtime as Closed (mobile, web, or RideOps). |
Blocking | An active downtime with an open assignment attached. If assignments are auto-created for downtime, blocking is the initial state. | Resolve the linked assignment (then downtime becomes resolved). |
Resolved | The downtime is resolved and the location is back in operation (or can be). | Admin finalizes it by closing the downtime in the web app. |
Closed | The downtime is finalized and counted as historical reporting. | Closing is the final step; only closed downtimes are logged historically. |
Note: If a downtime is blocking, the location cannot be reopened until the related assignment is resolved.
Registering downtime (high-level workflow)
Start a downtime from the mobile app
From Operations, select a location and add the downtime details (description, categories, attachments), then save.
Expected result: The location will show an active downtime (open or blocking depending on your settings).
Close a downtime in the web app
Once the location is back in operation (resolved), an admin closes the downtime to finalize reporting and ensure it’s logged historically.
Expected result: The downtime moves to closed and becomes part of historical reporting.
General terminology (used across downtime + operational logging)
Open/close events: marking a location “in operation” (open) or “out of operation” (close).
Downtime registration: one recorded downtime incident.
Downtime categories: admin-configured causes applied to a downtime (a downtime can have multiple).
Actual downtime: the total out-of-operation time finalized when admins close the downtime.
Operational log: the timeline of open/close events (and edits) that drives operational hours reporting.
Troubleshooting (common “gotchas”)
I don’t see the Operations tile: you likely don’t have access to any locations with Operational logging enabled.
I can’t reopen a location: check for an active blocking downtime with an unresolved assignment.
My downtime reporting seems inflated: verify you’re only counting time the location should have been operating (based on your operational logging practices).
Frequently asked questions
Q: What makes a downtime “blocking”?
A: A downtime becomes blocking when an open assignment is attached (manually or automatically, depending on your settings).
Q: Why do I still see a downtime after the location is back in operation?
A: The downtime may be resolved but not closed yet. Closing is the final step that finalizes historical reporting.
Q: Can a downtime exist without an assignment?
A: Yes — that is typically an open downtime. Assignments are optional and depend on your configuration and workflow needs.