Uptime is the most fundamental performance metric for any customer-facing kiosk. Everything else about the kiosk experience, the quality of the application, the relevance of the content, the speed of the interface, assumes the device is on and functioning when a customer approaches it. A kiosk that is offline, frozen, or displaying an error screen is not delivering a substandard experience. It is delivering no experience at all.
Yet most organizations that operate kiosk fleets do not have a defined uptime standard, do not measure actual uptime consistently, and do not have the operational infrastructure to identify and resolve downtime events quickly enough to maintain meaningful availability. The result is a fleet that functions acceptably on average while quietly accumulating hours of downtime at individual locations that nobody is tracking.
This guide defines what good kiosk uptime actually looks like, what causes it to degrade, and how Moki’s MDM platform provides the management foundation that makes a high uptime standard achievable and maintainable.
Defining the Kiosk Uptime Standard
Kiosk uptime is typically expressed as a percentage of scheduled operating hours during which the device is on and functioning correctly. A kiosk that operates 12 hours per day and is offline for 30 minutes during a given month has an uptime of approximately 99.3 percent for that period.
The appropriate uptime target varies by use case and operational consequence of downtime:
For revenue-generating kiosks including self-ordering terminals and self-checkout devices, 99 percent or higher is the operational standard. At 99 percent uptime over a 12-hour operating day, the device is offline for a maximum of approximately 7 minutes per day on average. Any more than this represents meaningful revenue exposure for high-traffic devices.
For customer-experience kiosks including product discovery, loyalty enrollment, and information terminals, 98 to 99 percent is a reasonable target. These devices have indirect revenue impact rather than direct transaction processing, but extended downtime still represents a failed customer touchpoint and erodes the value of the hardware investment.
For wayfinding and information displays in healthcare, hospitality, and corporate environments, 99 percent or higher is appropriate given that these devices serve a functional navigation purpose where downtime has operational consequences beyond customer experience.
Most unmanaged kiosk fleets fall significantly below these targets, with effective uptime rates in the 93 to 96 percent range when incidents are properly measured. The gap between actual and target uptime represents both the operational opportunity that MDM addresses and the business case for the investment.
What Degrades Kiosk Uptime
Understanding the causes of kiosk downtime is the foundation for addressing it systematically. Downtime events cluster into a small number of categories that each have specific prevention or detection mechanisms.
Application crashes are the most common cause of kiosk downtime. The kiosk application stops running, the device drops to whatever state is behind the application, and the device is effectively unavailable until someone restarts the application or reboots the device. Without monitoring, this event goes undetected until someone physically approaches the device or a location manager reports it. With Moki’s application monitoring and alerting, an app crash fires an alert within minutes and in many cases the remote reboot resolves the issue before any customer interaction is affected.
Network connectivity loss is the second most common cause. The device loses its connection to the network, which may affect the application’s ability to function if it requires connectivity, and also severs the MDM monitoring connection. A device that loses connectivity and regains it quickly, within the alert threshold window, is typically resolved without intervention. A device that stays offline triggers an alert and initiates investigation.
Memory accumulation is a slower degradation mechanism that causes progressive performance decline rather than sudden downtime. Applications that do not fully release memory between sessions accumulate memory usage over the operating day, eventually causing sluggish performance, increased crash frequency, and ultimately requiring a reboot to restore normal function. Scheduled nightly reboots through Moki’s automation capabilities prevent this accumulation from reaching the point of customer-visible performance degradation.
Hardware failures including degraded batteries, failed displays, and damaged components cause downtime that cannot be resolved remotely. The MDM contribution here is speed of detection: a device that goes offline due to hardware failure is identified and reported through Moki’s monitoring immediately, allowing field service to be dispatched as quickly as possible rather than discovering the failure hours or days later.
Unplanned OS or application updates that push during operating hours and require a reboot are a preventable cause of downtime. Updates that are not managed through the MDM platform’s controlled deployment process can apply at any time, including during peak customer traffic. Moki’s scheduled update capabilities confine updates to defined maintenance windows, eliminating this downtime category entirely.
The MDM Infrastructure That Maintains the Standard
Achieving and maintaining a 99 percent or higher kiosk uptime standard requires three operational capabilities working in concert: continuous monitoring that detects downtime events as they occur, a fast remote response mechanism that resolves the majority of incidents without field visits, and preventive maintenance automation that eliminates predictable downtime causes before they occur.
Moki’s real-time device monitoring provides continuous visibility into the online status, application health, battery level, memory usage, and connectivity state of every enrolled device. Alert thresholds configured for each device type ensure that the operations team is notified within minutes of a downtime event rather than discovering it through customer complaints.
Remote reboot and remote management capabilities allow the operations team to resolve the majority of common downtime causes, including app crashes, memory accumulation, and connectivity drops, without dispatching a technician to the location. For Android and BrightSign devices, full remote screen view and interactive control give the support team the ability to see exactly what is happening on the device and interact with it directly.
Scheduled maintenance automation prevents predictable downtime causes from occurring. Nightly reboots during off-hours prevent memory accumulation. Update deployment windows prevent unplanned in-hours updates. Configuration compliance monitoring prevents gradual drift from the intended device state.
Measuring Uptime Across the Fleet
Uptime cannot be managed without being measured. Moki’s reporting capabilities provide the data to calculate actual uptime for individual devices, device groups, and the entire fleet. The inputs are the alert history showing when devices went offline and came back online, combined with the device’s scheduled operating hours.
Reviewing uptime metrics on a defined cadence, weekly at minimum for high-revenue devices and monthly for the broader fleet, surfaces the devices and locations that are consistently underperforming. A device that regularly falls below the target uptime is a candidate for hardware inspection, connectivity investigation, or configuration review, depending on the pattern of its downtime events.
This data also provides the evidence base for the managed service value conversation with clients. A monthly report showing that average fleet uptime improved from 94 percent to 99.1 percent following MDM deployment is a concrete demonstration of operational value that justifies both the MDM investment and the ongoing managed service relationship.
Setting the Standard Before Deployment
The uptime standard should be defined before the first device is deployed, not after a pattern of downtime events forces the conversation. Defining the target, configuring the monitoring and alert thresholds to detect deviations, and establishing the response process all need to be in place when devices go live.
A deployment that goes live with monitoring configured and alert thresholds set has a baseline uptime measurement from day one. A deployment that goes live without monitoring establishes a pattern of reactive response that is harder to break once it is the operational norm.
Schedule a Moki demo to see how the monitoring, alerting, and remote management capabilities work together to maintain a high kiosk uptime standard, or start a free trial to begin measuring your current fleet’s actual uptime as a baseline. Moki’s digital kiosk page covers the full capability set for kiosk uptime management.