Инструкции по подключению

Передавайте события в привычные рабочие системы

Создавайте задачу при сбое и обновляйте её после восстановления сайта. Ниже — схемы подключения через webhook и модуль проверки событий для вашего разработчика.

Открыть настройки14 дней бесплатно · без банковской карты
01
События
Сбой и восстановление
02
Данные
Подписанный JSON
03
Подключение
Через ваш обработчик

Что понадобится для подключения

В кабинете выберите «Своя система · подписанный webhook», укажите публичный HTTPS-адрес и сохраните ключ подписи. Приведённые ниже схемы требуют настройки в выбранной системе; готового подключения в один клик у них пока нет.

  1. 01

    Адрес приёма событий

    Он должен быть доступен по HTTPS без перенаправлений, логина, параметров запроса и нестандартного порта. Ключ подписи хранится только у вашего обработчика.

  2. 02

    Проверка и сохранение

    Обработчик проверяет подпись исходного запроса, сохраняет событие в постоянную очередь и только затем возвращает успешный ответ.

  3. 03

    Действие в рабочей системе

    Сценарий создаёт задачу, обновляет её или отправляет сообщение. Для нескольких систем обработчик направляет событие по нескольким адресам и отдельно отслеживает результат каждого действия.

Помимо основного webhook-канала можно добавить ещё четыре в разделе «Дополнительные каналы». Для каждого отдельно выбираются сервис, сайты и события. Подписанный webhook использует собственный ключ каждого подключения. Почта, Telegram и браузерные уведомления работают параллельно. Доступность и стоимость сторонних платформ зависят от их условий.

Модуль проверки и пример события

Модуль для Node.js 22+ проверяет подпись, время отправки и структуру запроса. Он также готовит поля для маршрутизации и тело события PagerDuty. Зависимости устанавливать не нужно.

Это библиотека для вашего обработчика, а не готовый сервер или импортируемый сценарий. Она не хранит события, не создаёт подключения и ничего не отправляет во внешние системы.

import {
  verifyCoreMonitorWebhook,
  routeCoreMonitorEvent,
  toPagerDutyEvent,
} from "./core-monitor-webhook.mjs";

// rawBody: Buffer исходного HTTP-запроса, до JSON.parse
// headers: заголовки этого же запроса
const event = verifyCoreMonitorWebhook({
  rawBody,
  headers,
  secret: process.env.CORE_MONITOR_WEBHOOK_SECRET,
});
const route = routeCoreMonitorEvent(event);

// Сначала сохраните event + deliveryKey в постоянную очередь.
// Ответ 2xx допустим только после успешной записи.
// Отдельный обработчик очереди выполняет внешнее действие.

// Необязательно: тело запроса PagerDuty, без отправки.
const pagerDutyBody = toPagerDutyEvent(
  event,
  process.env.PAGERDUTY_ROUTING_KEY,
);

Ограничьте тело HTTP-запроса до 64 КБ ещё при чтении потока. Передавайте точные байты без повторной сериализации JSON. Модуль допускает расхождение времени до пяти минут; синхронизируйте часы сервера. Ключи не должны попадать в браузер, журналы и публичный репозиторий.

JSON-файл содержит вымышленные данные для настройки полей. Он не является подписанным запросом и сам по себе не пройдёт проверку. Реальное тестовое сообщение имеет тип notification.test и не содержит сайт или инцидент.

Один сбой — одна задача

У доставки и у инцидента разные идентификаторы. deliveryKey защищает от повторной обработки запроса, а incidentKey связывает сбой с восстановлением.

Соответствие событий Core Monitor действиям в рабочей системе
СобытиеactionДействие
notification.testtestЗаписать результат проверки, не создавать задачу
incident.openedopenСоздать задачу, если её ещё нет
incident.recoveredresolveОбновить связанную задачу или отметить восстановление
incident.escalatedremindНапомнить о той же проблеме, без новой задачи

Запись deliveryKey и постановка в очередь должны быть одной атомарной операцией. Повтор уже сохранённого запроса можно подтвердить 2xx. Если хранилище недоступно, верните 503. Рекомендуем хранить ключи доставок не меньше семи дней, а связь инцидента с задачей — на весь срок работы с ней.

Повторы могут прийти не по порядку. Если восстановление уже обработано, не открывайте тот же инцидент заново по опоздавшему сбою или напоминанию. При восстановлении без найденной задачи сохраните закрытое состояние, чтобы поздний запрос не создал ложную тревогу.

n8n, Albato, Make и Zapier

У конструктора должен быть отдельный шаг проверки подписи либо проверяющий обработчик перед ним. Не запускайте рабочие действия только потому, что запрос пришёл на секретную ссылку.

n8n

  1. Создайте Webhook с методом POST. Включите Raw Body, чтобы проверка подписи получила исходное тело запроса и заголовки.
  2. Проверьте подпись и сохраните событие в постоянную очередь. Используйте Respond to Webhook для ответа после сохранения, а не Immediately до проверки.
  3. Разделите события по action и настройте нужные действия. Опубликуйте сценарий и укажите в Core Monitor Production URL — тестовая ссылка работает только во время ожидания теста.

Скачиваемый модуль предназначен для Node.js, а не для импорта как готовый workflow n8n. Если ваша установка не позволяет работать с исходными байтами и криптографией, используйте отдельный обработчик перед n8n.

Инструкция n8n (в новой вкладке)

Albato

  1. Создайте подключение «Входящий вебхук» и включите ожидание данных. Скопируйте его адрес в настройки своего обработчика.
  2. В Core Monitor укажите адрес обработчика, который проверит подпись, исключит дубли и передаст подтверждённое событие в Albato.
  3. В связке выберите «Входящий webhook» и сопоставьте поля с нужным действием. Для настройки полей инцидента используйте JSON-пример из раздела шаблонов, а проверку подключения направьте в отдельную ветку.

Не считайте секретную ссылку заменой проверки HMAC. Получение данных в Albato ещё не означает, что задача или сообщение в конечном сервисе созданы.

Инструкция Albato (в новой вкладке)

Make

  1. Создайте сценарий с Webhooks → Custom webhook и получите адрес приёма.
  2. Передавайте в него события из проверяющего обработчика. Обработчик хранит ключ Core Monitor, проверяет подпись и сохраняет событие до ответа 2xx.
  3. Добавьте Router с ветками для теста, сбоя, восстановления и напоминания. Храните связь между incidentKey и созданной задачей, чтобы восстановление обновляло её, а не создавало новую.

Make может принять запрос в очередь до завершения сценария. Ошибки следующих шагов проверяйте в истории Make и обрабатывайте отдельно. При параллельных запусках нужна атомарная защита от дублей.

Инструкция Make (в новой вкладке)

Zapier

  1. Создайте Zap с Webhooks by Zapier. Catch Raw Hook нужен, если вы проверяете исходное тело и заголовки внутри сценария; после внешней проверки можно использовать Catch Hook.
  2. Проверьте подпись до любых действий. Если шаги Zap не сохраняют исходные байты или не дают проверить HMAC, поставьте перед Zap проверяющий обработчик.
  3. Отделите тест от событий инцидента, добавьте поиск по incidentKey и настройте создание или обновление задачи. После публикации проверьте результат в истории Zap.

Ответ webhook подтверждает приём, а не успех всех шагов Zap. Обработчик и сценарий должны самостоятельно повторять неудачные действия после принятого запроса.

Инструкция Zapier (в новой вкладке)

Битрикс24, PagerDuty и Jira

У этих систем свои форматы запросов и способы авторизации. Адрес REST API нельзя просто вставить в Core Monitor: обработчик должен проверить событие и преобразовать его.

Битрикс24

После проверки события вызовите REST API из своего обработчика или конструктора. При сбое создайте задачу ответственному, при восстановлении обновите ту же задачу по сохранённому ID.

«Входящий вебхук» Битрикс24 даёт доступ к методам REST, а не принимает произвольные события Core Monitor. Выдайте ему только нужные права. URL с ключом храните как пароль; задачи автоматически не закрывайте, если команде нужна ручная проверка.

Документация Битрикс24 (в новой вкладке)

PagerDuty

Подключите Events API v2 к нужному сервису. Функция toPagerDutyEvent готовит trigger при сбое и resolve при восстановлении с одинаковым dedup_key. Сам запрос отправляет ваш обработчик.

Используйте ключ интеграции, не REST API token. Проверочные сообщения и напоминания функция пропускает: эскалацию настраивают в PagerDuty. До отправки проверяйте закрытое состояние инцидента, чтобы поздний сбой не открыл его снова.

Формат событий PagerDuty (в новой вкладке)

Jira Service Management

В Automation создайте правило с Incoming webhook. В обработчике добавьте секрет Jira в заголовок X-Automation-Webhook-Token и отправляйте только проверенные события.

В правиле сопоставьте поля, выберите проект и тип задачи. Сохраняйте ключ созданной задачи рядом с incidentKey; восстановление должно обновлять её. Успех проверяйте по журналу Automation и самой задаче.

Настройка Jira Automation (в новой вкладке)

Что проверить перед включением

Проверяйте не только ответ на webhook, но и результат в конечной системе. В Core Monitor статус отправки означает, что адрес принял запрос, а не что все действия вашего сценария завершились.

  • Проверочное сообщение дошло, но не создало рабочую задачу или тревогу.
  • Неверная подпись и изменённое тело отклоняются до любых действий.
  • Два одновременных запроса с одним deliveryKey создают только одну запись в очереди.
  • После перезапуска обработчик помнит дубли и продолжает сохранённые задания.
  • Восстановление обновляет нужную задачу; опоздавший сбой не открывает её снова.
  • Ошибка конечной системы остаётся видна в вашей очереди и повторяется по её правилам.
  • В журнале нет ключей, секретных URL и лишних данных. Выбраны подходящие права, регион хранения и условия обработки данных внешней платформы.

Модуль и преобразования проверены автоматическими тестами. Настройку конкретного аккаунта внешней системы нужно проверить отдельно: эта инструкция не означает, что он уже подключён к вашему кабинету.

Начните бесплатно

Начните с проверочного сообщения

Настройте обработчик, затем нажмите «Проверить отправку» в кабинете. Убедитесь, что сообщение дошло до конца вашего сценария.

Открыть настройки