Мониторинг вебхука: как поймать падение эндпоинта до того, как его заметит клиент

Мониторинг вебхука: как поймать падение эндпоинта до того, как его заметит клиент

Смотрим в тело запроса, но сначала проверяем сам хендлер: healthcheck должен отвечать отдельно от боевого URL, иначе вы будете радоваться живому `/ping`, пока основной endpoint уже ловит 5xx на ровном месте. Для вебхуков важны три сигнала: код ответа, задержка обработки и доля повторных доставок. Если провайдер начал ретраить — это уже инцидент, а не “шум”.

Не алертите на каждый 500-й ответ. Ставьте окно и порог: например, 3–5 ошибок подряд или резкий рост p95 latency. Идемпотентность — это не роскошь, а база: если хендлер упал после записи в БД, повторный приход payload не должен создавать дубль. Храните event_id, hash полезной нагрузки или внешний delivery_id, чтобы быстро отличить дубль от нового события.

Логируйте минимум: request_id, source IP, headers без секретов, размер body, статус квитирования, время до ответа. В алерт кладите не только “упало”, но и контекст: какой маршрут, какой upstream, какая ошибка парсинга. Если JSON битый, не пытайтесь “починить” его на лету — отправляйте в dead-letter или quarantine, иначе мусор тихо съест пайплайн.

Финал простой: мониторим не только доступность URL, но и семантику доставки — ретраи, дубли, лаг и битую полезную нагрузку. Тогда падение видно не по жалобам пользователей, а по вашей метрике.