IPSC3 includes an independent ipsc3-monitor service. It does not run in the DMR packet loop,
POC RTP loop, or a dashboard request, so monitoring cannot delay live audio.
The monitor samples:
/api/health HTTP endpointSELECT 1If MySQL is unavailable but ipsc3.service remains active, the IPSC heartbeat is shown as unknown
rather than creating a duplicate IPSC alarm. The MySQL failure remains a separate alarm.
Failure and recovery confirmation counts are configurable. The defaults require two consecutive
failed checks to turn an alarm on and two consecutive successful checks to turn it off. Pushover
notifications are emitted only for those transitions, not on every sample while an alarm remains
active.
Alarm notifications use high priority. Recovery notifications use low priority. Emergency/repeating
priority is intentionally not used.
Administrators configure monitoring under Configuration > Monitoring. Available controls include:
Pushover requires both a 30-character application token and a 30-character user/group key. Values
are stored in a mode-0600 runtime configuration file. Existing values are never returned to the
browser; the dashboard only reports whether each value is configured.
The Monitoring tab displays current state for each check and a bounded alarm history with local time,
alarm-on/alarm-off transitions, details, and Pushover delivery status. Runtime files are stored under
/opt/ipsc3/runtime/monitor by default. The monitor's own operational output is available through:
journalctl -u ipsc3-monitor.service