Webhook-алерты: инциденты в ваши системы
Почта и Telegram не исчерпывают сценарии. Webhook-контакты шлют события на ваш HTTPS endpoint — дальше маршрутизация, тикеты и on-call остаются у вас.
Когда выбирают webhook
Уже есть бот, тикет-система или свой on-call — webhook убирает ручной перенос текста.
Как устроены контакты
URL webhook добавляется как контакт оповещений и назначается мониторам, как email или Telegram.
Ожидания к payload
Endpoint должен принимать HTTPS POST от SitePuls; подписи и секреты — по вашей модели безопасности.
Повторы и ошибки
Логируйте на приёме, следите за таймаутами и идемпотентностью.
По сравнению с email
Почта для людей; webhook — для автоматизации.
По сравнению с Telegram
Telegram — человеческий канал; webhook — для машин, часто используют оба.
Чего SitePuls не делает
Готовых коннекторов «на всё» — даётся URL; дальше вы сами вешаете Slack, Jira и т.д.
Дальше
Создайте webhook-контакт, проверьте доставку, затем повесь на самые важные мониторы.
Что можно проверять в SitePuls на этой странице
- Контакты-вебхуки отправляют JSON методом POST на HTTPS-URL из контакта.
- Опциональный общий секрет — в заголовке X-SitePuls-Token, если задан в контакте.
- В настройках контакта выбирают режим полезной нагрузки: generic JSON или Slack-формат.
Куда уходят оповещения об инцидентах
- Адреса электронной почты в контактах получают письма при открытии и закрытии инцидентов (в рамках настроек уведомлений).
- Уведомления в Telegram через бота SitePuls после привязки чата к контакту (включая сценарий /start для ожидающих контактов).
- HTTPS-вебхуки с JSON: тип события, идентификаторы монитора, статус, время, при необходимости id инцидента и короткое сообщение — для своих интеграций.
- Режим Slack-compatible incoming webhook: отдельный формат полезной нагрузки в настройках контакта.
Иллюстративный пример: имена полей как в продукте, значения — вымышленные.
Пример: JSON тела generic webhook
{
"event_type": "down",
"monitor_id": 123,
"monitor_name": "Пример API",
"monitor_type": "http",
"status": "down",
"timestamp": "2026-03-31T12:00:00Z",
"message": "Последняя проверка не прошла (пример)",
"incident_id": 456
}Пример: payload в стиле Slack incoming webhook
{
"text": "🔴 *DOWN*\nMonitor: Пример API (http)\nTime: 2026-03-31 12:00:00 UTC\nПоследняя проверка не прошла (пример)\nIncident ID: 456"
}Вопросы и ответы
Есть встроенный Slack?
Используйте incoming webhook Slack или мост — отдельный OAuth Slack внутри SitePuls не обязателен для базовой доставки.
Можно JSON?
Смотрите формат payload в документации приложения.
Шифрование?
Используйте HTTPS и авторизацию endpoint по угрозам.
Разные webhook на монитор?
Назначайте контакты явно по мониторам.
Webhook заменяет список инцидентов?
Нет — в UI инциденты остаются; webhook — копия наружу.
Лимиты частоты?
Избегайте петель: отвечайте быстро и без лишних повторных побочных эффектов.
Тест без реального сбоя?
Используйте тест контакта в приложении или временный request bin.
Где документация?
Контакты и мониторы настраиваются в веб-приложении после входа.