Operational summary
When an operator triggers SOS from a device or the app, the dashboard raises a high-priority alert and may focus the map on the last known fix.
Use the unit detail panel to review identity, last-seen time, and clear tactical alerts when appropriate. Platform-level SOS may use the hub acknowledgement flow.
Deep dive
SOS is Sentinel's most critical function: when it fires, everything else takes a back seat. The operator can trigger it from a node hardware button or the mobile app. Either way, the backend processes it with maximum priority and notifies the dashboard immediately.
When an SOS arrives, the panel responds with multiple simultaneous signals: visible HUD alert, accelerated orange animation on the node marker, possible automatic map focus on the last known position, highlighted entry in the tactical log. The idea is to make it impossible to miss, even if the operator is looking at another tab.
Suggested response protocol: confirm unit identity and read last position; attempt voice contact via the SOP's agreed channel; dispatch response mission or backup team if appropriate; document the incident. Sentinel does not replace your operational protocol: it's the visibility and coordination layer on top of the SOP. Voice, radio, human contact remain critical.
A decision we see organizations make as they mature with Sentinel is separating the technical resolution of the incident (closing the SOS flag) from the operational resolution (confirming the operator is OK, completing internal report). Closing SOS in software without operational sign-off can create false sense of closure. Keep the incident open in the panel until truly resolved.
Key takeaways
- Use voice or internal protocol before closing the incident in software.
- Record closure per your standard operating procedures.
Open in product