There are two ways to find out a customer-facing device has a problem. The first is when a customer, store manager, or employee contacts you to report it. The second is when your monitoring system tells you before anyone else notices.
The first scenario means the problem was already visible. A customer encountered a frozen kiosk, a dark signage display, or a POS terminal that would not complete a transaction. Time has already passed. Revenue may already be affected. The brand experience has already taken a hit.
The second scenario is what a properly configured alert system delivers. When Moki’s alert capabilities are set up correctly, your team gets a notification the moment a device goes offline, an app crashes, or battery drops to a level that threatens continuity. The problem is identified in real time and can often be resolved remotely before it is ever visible to a customer.
This guide covers how to approach alert configuration for a device fleet and what to set up for each major device type and deployment scenario.
Why Alert Configuration Gets Skipped
Alert setup is one of the most commonly under-configured elements of an MDM deployment. It gets skipped for a few consistent reasons: the initial setup focuses on enrollment and lockdown, alerts feel like a secondary concern, and the effort of defining thresholds and routing seems like something to come back to later. Later often never comes.
The cost of that omission is a reactive support posture. Problems surface through customer complaints rather than system notifications. Resolution time is longer because the team is starting from a call rather than from a monitoring alert with device context already attached. And the pattern repeats until alert configuration becomes a priority after one incident too many.
Building alert configuration into the standard deployment process, before devices go live, changes the operational model from the start.
Understanding What Moki Can Alert On
Moki’s monitoring system supports alerts across several categories of device events. Understanding the full range of alert triggers helps in deciding which ones matter most for a given deployment:
- Device connectivity: Alerts when a device goes offline or loses network connectivity for longer than a defined threshold
- Battery level: Alerts when a device’s battery drops below a specified percentage
- App health: Alerts when the managed application crashes or stops running
- Compliance state: Alerts when a device falls out of its expected configuration state
- Custom SDK events: For organizations using the Moki SDK within their own application, custom in-app events can be surfaced as alerts, enabling monitoring of application-specific conditions beyond device-level health
Each alert type can be configured with its own threshold, notification method, and recipient list, allowing different conditions to route to different people and trigger at different sensitivities.
Setting Alert Thresholds by Device Type
Not every device type warrants the same alert sensitivity. A kiosk that serves customers continuously has different tolerance for downtime than a signage display in a low-traffic corridor. Calibrating thresholds to the operational importance of each device type makes the alert system useful rather than noisy.
For point-of-sale terminals, downtime directly affects revenue. Alert thresholds should be tight:
- Offline alert: fire after 5 to 10 minutes of connectivity loss
- Battery alert: fire at 20 percent or higher to allow time for someone to plug in the device before it powers off
- App crash alert: fire immediately
For digital kiosk deployments in high-traffic customer areas, similar sensitivity applies. For kiosks in lower-traffic areas, a slightly wider offline threshold of 15 to 30 minutes may be appropriate to avoid alert fatigue from brief connectivity drops.
For digital signage displays, the tolerance depends on the content’s operational importance. Promotional signage can tolerate a longer offline window before triggering a response. Wayfinding displays in healthcare or hospitality settings where patients or guests depend on them should be treated with the same sensitivity as a POS terminal.
For devices in distribution centers or manufacturing environments where scanning or operational apps are in use, app crash alerts should be immediate since a down handheld blocks the workflow of the employee using it.
Routing Alerts to the Right People
An alert that goes to the wrong inbox is nearly as useless as no alert at all. Alert routing should match the organizational structure of the team responsible for device management and the escalation path for device problems.
A practical routing structure for most multi-location deployments looks like this:
- First-tier alerts (brief offline, low battery) route to the operations team or help desk for remote troubleshooting through the Moki dashboard
- Sustained offline alerts (device has been down beyond the remote troubleshooting window) escalate to a field service coordinator
- Compliance or configuration alerts route to the IT team responsible for MDM configuration
- Critical alerts across multiple devices at a single location simultaneously route to a senior operations or IT leader, since simultaneous failures may indicate a network outage at that site rather than individual device issues
Moki supports alert notifications via email. For organizations that want alerts integrated into their existing communication tools, webhook configurations can route alert data to Slack, Teams, or other systems where the relevant team is already working.
Avoiding Alert Fatigue
Alert fatigue happens when an alert system generates too many notifications, causing the team to start ignoring them. The solution is not fewer alerts. It is more precise alert configuration.
Several practices help keep alert volume manageable without missing real issues:
- Set offline thresholds that account for expected brief disconnections. A device that briefly loses connectivity during a reboot or a Wi-Fi handoff should not trigger an alert. A device that has been unreachable for 20 minutes should.
- Group devices intelligently so that an alert about a device group can be correlated. If 15 devices at one location all go offline simultaneously, that is one network outage, not 15 individual device failures, and it should be investigated as such.
- Review alert history periodically to identify devices that are generating repeated alerts. A device that consistently triggers low-battery alerts likely has a hardware problem, a bad charging setup, or a configuration issue that should be addressed rather than repeatedly alerted on.
- Suppress known maintenance windows by temporarily pausing alerts during scheduled updates or reboots so the team is not inundated with notifications from planned activity.
Testing Alerts Before Going Live
Alert configuration should be tested before devices are deployed to customer-facing locations. A configuration that looks correct in the dashboard but fails to deliver notifications is worse than no configuration at all because it creates a false sense of monitoring coverage.
Testing should confirm:
- That taking a device offline triggers the expected alert within the configured threshold window
- That the alert routes to the correct recipient via the correct notification method
- That resolving the alert condition (bringing the device back online) clears the alert appropriately
- That custom SDK events, if configured, fire under the conditions they are designed to detect
- That escalation logic works as expected if a first-tier alert goes unresolved
Running through this test on one device in each major device category before full deployment adds minimal time to the rollout and validates that the monitoring system is actually working.
Connecting Alerts to Remote Troubleshooting
Alerts are most effective when they are connected to an immediate remediation capability. Knowing a device is down is only useful if there is a fast path to fixing it. Moki’s remote management features give the team that path: when an alert fires, the responder can open the Moki dashboard, view the affected device’s current status, attempt a remote reboot, check app health, and push a configuration update if needed, all without anyone visiting the location.
For Android and BrightSign devices, full remote screen view and interactive control are available, allowing the responder to see exactly what is happening on the device and interact with it directly from their computer. For iOS devices, remote configuration, app pushes, and reboots are supported even without direct screen control.
The combination of real-time alerting and remote remediation is what makes the monitoring system operationally effective rather than just informational.
Schedule a Moki demo to see alert configuration and remote monitoring in action, or start a free trial to begin building out your alert configuration today. Moki’s support resources include documentation on specific alert setup steps for each device type and platform.