Как не проспать падение вебхука: мониторинг, который реально ловит 5xx

Как не проспать падение вебхука: мониторинг, который реально ловит 5xx

Смотрим в тело запроса, но сначала — в метрики. Для каждого эндпоинта нужны минимум: доля 2xx/4xx/5xx, p95 latency, таймауты, размер очереди и число ретраев. Если есть только uptime-check по GET /health — это декорация, а не мониторинг: бизнесовый POST может лежать, пока health гордо отвечает 200.

Алерт строится не на одном падении, а на паттерне: 3-5 ошибок подряд, рост latency выше порога, всплеск 429/503, остановка входящих событий. Разделяйте синтетический пинг и реальные события. Первый ловит сетевые проблемы, второй — битую полезную нагрузку, сломанный хендлер и лаги в зависимостях. Ретрай-политика решает всё: если очередь растёт, а ack не приходит, тревога должна срабатывать до того, как вы потеряете окно повторной доставки.

Логи — только структурированные: event_id, delivery_id, source, attempt, status, error_class, latency_ms. Без этого разбор превращается в археологию. Идемпотентность — это не роскошь, а база: один и тот же webhook должен безопасно пережить повторную доставку, иначе мониторинг будет показывать шум вместо проблемы.

Финал простой: алерт должен отвечать на вопрос не «упал ли сервер», а «теряем ли мы события прямо сейчас». Если ответ неочевиден — добавляйте метрики, корреляцию по event_id и отдельный канал для 5xx, а не надежду на удачу.