Привет, Habr!

Мы разрабатываем IncidentRelay - self-hosted систему для on-call scheduling, маршрутизации алертов и доставки уведомлений. Идея простая: дать командам SRE, DevOps, platform и operations понятный инструмент, который можно развернуть у себя, подключить к мониторингу и использовать без зависимости от внешней incident-management платформы.

Зачем еще один инструмент для алертов

Во многих командах алерты уже есть: Prometheus Alertmanager, Zabbix, webhooks от внутренних систем. Но между “система что-то прислала” и “ответственный человек это увидел, подтвердил и решил” часто остается много ручной логики:

  • кто сейчас on-call;

  • куда отправлять уведомление;

  • что делать, если человек не ответил;

  • как временно заменить дежурного;

  • как не потерять историю ACK / Resolve;

  • как не отдавать alert flow внешнему SaaS.

IncidentRelay закрывает этот промежуток.

Базовый поток выглядит так:

Monitoring system -> Route -> Team -> Rotation -> Notifications -> ACK / Resolve

Что такое IncidentRelay

IncidentRelay - это self-hosted веб-приложение и API для управления incident workflow.

Внутри есть несколько ключевых сущностей:

  • Groups - границы доступа и RBAC.

  • Teams - операционные команды.

  • Rotations - on-call графики и смены.

  • Routes - точки приема алертов с собственными intake tokens.

  • Services - затронутые системы и контекст влияния.

  • Channels - Mattermost, Telegram, email, webhook, voice call и другие способы доставки.

  • Alerts - события, которые можно acknowledge или resolve.

  • Silences - подавление шумных или известных алертов.

  • Escalations - повторные уведомления и переход к следующему ответственному.

Маршруты получают алерты, команды и ротации определяют ответственного, а каналы доставляют уведомления.

Интеграции

На входе поддерживаются:

  • Prometheus Alertmanager;

  • Zabbix;

  • generic webhook.

Для уведомлений доступны:

  • Mattermost;

  • Telegram;

  • Slack;

  • Discord;

  • Microsoft Teams;

  • email;

  • generic webhook;

  • voice call через pluggable provider API;

  • browser/PWA push для assigned user.

Browser push работает на уровне профиля пользователя, а не как обычный route channel. Пользователь включает push в профиле, после чего IncidentRelay может отправлять уведомления на его активные browser/PWA устройства.

On-call и routing

В IncidentRelay route имеет собственный intake token. Это помогает явно понимать, какой внешний источник имеет право создавать алерты в конкретном маршруте.

Ротации поддерживают on-call scheduling, overrides и layered schedules. Это полезно, когда у команды есть несколько уровней дежурства, временные замены или разные правила для разных периодов.

Если алерт не подтвержден, система может отправлять reminders и запускать escalation flow.

Почему self-hosted

Self-hosted подход важен не всем, но для некоторых команд он критичен:

  • алерты не уходят во внешний SaaS;

  • данные остаются внутри инфраструктуры;

  • можно контролировать сеть, БД, логи и доступы;

  • проще встроить систему в собственные operational policies;

  • можно дорабатывать интеграции под свои процессы.

IncidentRelay можно запускать через Docker Compose или устанавливать на RedHat-like дистрибутивы из RPM-репозитория. Также есть manual systemd установка.

API-first

У проекта есть Swagger/OpenAPI документация и personal API tokens. Это позволяет не только работать через UI, но и автоматизировать создание ресурсов, интеграции и внутренние процессы.

Для voice call предусмотрен provider API: можно подключить собственный провайдер звонков, реализовать callback-и, DTMF-действия и ACK / Resolve по кнопкам телефона.

Текущий статус

IncidentRelay сейчас находится в beta. Это значит, что API, схема БД, UI и конфигурация еще могут меняться. Но основные блоки уже есть: маршрутизация алертов, on-call ротации, уведомления, escalation, silences, service context, browser push и документация.

Проект открыт на GitHub:

https://github.com/roxy-wi/IncidentRelay

Документация:

https://incidentrelay.io/docs/

Для кого это может быть полезно

IncidentRelay может подойти, если:

  • вы хотите self-hosted alternative для incident workflow;

  • у вас уже есть Alertmanager, Zabbix или webhook-based monitoring;

  • нужно маршрутизировать алерты по командам и ротациям;

  • хочется иметь ACK / Resolve, reminders и escalation;

  • SaaS для алертов нежелателен по требованиям безопасности или инфраструктуры;

  • нужна возможность доработать уведомления и интеграции под себя.

Заключение

IncidentRelay не пытается быть огромной incident-management платформой “для всего”. Мы скорее идем от практического сценария: принять алерт, понять команду и ответственного, доставить уведомление, дать возможность подтвердить или закрыть событие и сохранить контроль внутри своей инфраструктуры.

Будем рады обратной связи, идеям и issue на GitHub.