Ability to call for an alert. #102
Description
Discussed in #65
Originally posted by hoosierscanner January 12, 2026
I’d like to propose a feature that would significantly improve operational visibility and admin-level monitoring for ThinLine Radio installations.
Requested Capability
Add support for admin alerts via outbound webhooks and/or a simple REST API, allowing ThinLine Radio to send system and health notifications to external services.
Primary Use Cases
• ThinLine Radio health checks (service up/down, stalled ingest, failed uploads)
• Nightly or scheduled server statistics (CPU, memory, disk usage, queue depth)
• Temperature or hardware alerts (for on-prem installs)
• Error thresholds (e.g., repeated decoder failures, API failures, storage nearing capacity)
Key Design Requirement
The alert mechanism should be callable:
• From the ThinLine Radio server itself, and
• From an external system, so alerts can still fire if trunk-recorder is running on a separate host or is currently down.
This would allow admins to:
• Trigger alerts from cron, systemd timers, or external watchdogs
• Integrate with monitoring tools (Grafana, Prometheus exporters, Uptime Kuma, etc.)
• Forward alerts to Slack, Discord, email, PagerDuty, or custom dashboards
Suggested Implementation (flexible)
• Outbound webhook support (HTTP POST with JSON payload)
• Optional authenticated REST endpoint for submitting admin alerts
• Configurable alert types and severity levels
• Minimal schema such as:
• source
• severity
• message
• timestamp
• optional metadata (host, site, system, etc.)
Why This Matters
ThinLine Radio is often deployed in unattended or multi-system environments. When issues occur, admins usually find out only after users report missing audio. A built-in alerting mechanism would:
• Reduce downtime
• Improve reliability perception
• Make ThinLine Radio easier to operate at scale