Why self-host an on-call platform?
On-call systems contain sensitive operational data: employee schedules, contact details, alert payloads, service names, incident timelines and links to internal systems. Some teams prefer to keep that information within their own network and database.
Self-hosting also gives teams control over deployment timing, integrations, retention, backups and access boundaries. The trade-off is straightforward: you operate the platform and own its availability. There is no magic cloud, only a computer receiving invoices somewhere else.
What IncidentRelay includes
- On-call schedules, rotation layers and temporary overrides.
- Alert routing for Alertmanager, Zabbix, Sentry and generic webhooks.
- Escalation policies, reminders and responder requests.
- Services, dependencies, maintenance windows and incident priorities.
- Mattermost, Telegram, email, browser push, webhook and voice notifications.
- Personal API tokens and OpenAPI documentation.
Deployment choices
IncidentRelay supports several deployment models so teams can use familiar operational tooling.
| Method | Typical use |
|---|---|
| Docker Compose | Evaluation, smaller environments and straightforward container deployments. |
| RPM packages | Red Hat-like Linux systems managed through package and systemd workflows. |
| Manual systemd | Source-based deployments and custom Python environments. |
| Helm chart | Kubernetes deployments with separate web, scheduler and optional Telegram workers. |
Database and scaling choices
SQLite is available for small, single-node installations. PostgreSQL is the practical choice for larger or longer-running environments, higher alert volume and deployments with multiple web workers. The scheduler runs as a separate process so reminders and escalations are not duplicated across web workers.
Integrate with the stack you already run
IncidentRelay acts as a routing layer between monitoring systems, service ownership, schedules and notification destinations. Routes have their own intake tokens and determine where incoming alerts go. Channels describe how the selected responder is notified.
Generic webhooks and OpenAPI endpoints make it possible to connect internal tools without waiting for a vendor-specific integration. Custom voice providers can be installed for teams that operate their own telephony workflow.
Operational responsibilities
A self-hosted incident platform should be treated like production infrastructure. Plan database backups, monitor the web and scheduler services, test notification channels and keep an emergency path for incidents affecting IncidentRelay itself.
APIs, configuration and schema may evolve between releases, so review release notes and test upgrades before production rollout.