Во второй половине августа 2026 года состоялся релиз открытого проекта IncidentRelay 2.0 — системы для организации дежурств, маршрутизации оповещений и сопровождения инцидентов, разворачиваемую на собственном сервере (self‑hosted). Исходный код решения написан на Python и опубликован на GitHub под лицензией MIT. Первая стабильная версия IncidentRelay вышла в июле 2026 года.
По информации OpenNET, проект IncidentRelay ориентирован на SRE, DevOps и инфраструктурные команды, которым требуется локальная альтернатива облачным платформам управления дежурствами.
Решение IncidentRelay принимает события из Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma и произвольных webhook‑обработчиков. После нормализации в IncidentRelay событие связывается с сервисом, командой и ротацией, к нему применяются правила маршрутизации и политики эскалации, после чего уведомление направляется текущему дежурному. Для доставки в IncidentRelay поддерживаются Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, browser/PWA push и провайдеры голосовых вызовов.
Главным новшеством IncidentRelay 2.0 стал механизм Event Orchestration, предоставляющий отдельный слой обработки событий между входящими интеграциями и жизненным циклом алерта.
Основные изменения и доработки в IncidentRelay 2.0:
добавлен визуальный редактор правил оркестрации. Правила могут применяться глобально или к отдельному сервису, объединяться во вложенные группы условий и последовательно изменять приоритет, уровень важности, метки, команду, маршрут, способ группировки, политики уведомлений и эскалации;
реализованы действия для подавления, отбрасывания и приостановки обработки событий, извлечения значений при помощи регулярных выражений и JSON Path, разделения строк, создания переменных и преобразования значений;
конфигурация оркестрации разделена на редактируемые черновики и неизменяемые опубликованные версии. Поддерживаются проверка конфигурации, публикация, откат на предыдущую версию и добавление комментариев к изменениям;
предусмотрены режимы disabled, shadow и active. В режиме shadow результаты выполнения правил сохраняются для анализа, но не влияют на реальную маршрутизацию. Для переходного периода доступны режимы совместимости legacy, hybrid и orchestration;
добавлены средства симуляции и повторного воспроизведения событий. Они позволяют проверить правила на нормализованном событии или исходном payload интеграции без создания реального алерта. Для анализа результатов предоставляются трассировка выполнения, Explain‑данные и метрики теневого режима;
реализованы переиспользуемые webhook‑действия, выполняемые асинхронно после обработки события. Заголовки хранятся в зашифрованном виде, секреты скрываются в API и журналах, а обращения к частным сетям по умолчанию запрещены. Можно настроить тайм‑ауты, повторные попытки и список разрешённых внутренних адресов;
добавлена интеграция с Uptime Kuma, принимающая стандартные webhook‑сообщения о состоянии мониторов. Реализованы нормализация состояний UP и DOWN, определение важности, обработка тегов и новый тип входящего маршрута uptime_kuma;
для silences и окон плановых работ появились параметры apply_to_existing и reactivate_on_end. Первый позволяет применить подавление к уже открытым алертам, а второй определяет, следует ли возобновить их обработку после завершения периода подавления. Приостанавливаются и восстанавливаются уведомления, напоминания и цепочки эскалации;
для персональных API‑токенов введены раздельные права чтения и изменения групп, команд, пользователей, маршрутов, каналов, сервисов, ротаций, политик, окон обслуживания, heartbeat‑проверок, SSO и оркестраций. Старые агрегированные права resources:read, resources:write и * сохранены для обратной совместимости;
добавлен интерфейс журнала аудита с фильтрацией и постраничным выводом. В журнале фиксируются операции с оркестрациями, webhook‑действиями, silences и окнами плановых работ, при этом конфиденциальные значения удаляются из отображаемых данных;
в веб‑интерфейсе появилась тёмная тема и пользовательские настройки языка и оформления. Добавлена французская локализация, расширены переводы разделов оркестрации и обслуживания, исправлено редактирование правил сопоставления групп SSO;
улучшена работа heartbeat‑проверок: исключено повторное создание событий о просрочке, восстановление сигнала корректно закрывает алерт и отправляет уведомление о решении проблемы, унифицировано представление временных меток;
подготовлена документация по развёртыванию в Kubernetes при помощи Helm. В Helm‑чарт добавлен отдельный обработчик Slack Socket Mode, необходимый для работы интерактивных кнопок подтверждения и закрытия инцидентов;
усилена защита исходящих HTTP‑запросов, регулярных выражений и конфиденциальных данных, централизована обработка UTC и часовых поясов, переработаны вычисления расписаний ротаций и расширено покрытие автоматическими тестами.
Перед обновлением до IncidentRelay 2.0 рекомендуется создать резервную копию базы данных. Необходимые изменения схемы выполняются штатным механизмом миграций IncidentRelay. Для постепенного внедрения Event Orchestration разработчики проекта рекомендуют сначала использовать режимы shadow и hybrid, проверить трассировки выполнения правил и только после этого переключать оркестрацию в режим active.
