Почему webhook “тихо умер”: схема мониторинга, которая ловит падение раньше клиентов

Почему webhook “тихо умер”: схема мониторинга, которая ловит падение раньше клиентов

Если у вас есть эндпоинт, который только принимает события, то отсутствие трафика — не тишина, а возможная авария. Смотрим в тело запроса, но сначала проверяем, что запрос вообще дошёл: отдельный health-check, synthetic ping и метрика по входящим 2xx/4xx/5xx. На глаз это не видно, а ночью это обычно уже инцидент.

Минимальный набор сигналов:
• latency p95/p99 по хендлеру
• доля 5xx и таймаутов
• рост 429 от вашего же rate limit
• отсутствие событий в окне, где они обязаны быть
• расхождение между “принято” и “обработано” в очереди

Алертить надо не на каждый 500-й ответ, а на паттерн: нет трафика N минут, подряд N ошибок, очередь растёт, а consumer молчит. Идемпотентность — это не роскошь, а база: повторный webhook должен либо пройти как дубль, либо быть безопасно отклонён по event_id. Иначе ретрай-политика внешнего сервиса превратит вам мониторинг в генератор мусора.

Практика простая: на входе пишем сырую полезную нагрузку, ставим correlation_id, сразу отдаём 200 только после валидации и успешной постановки в очередь. Если downstream лежит, алерт должен прилетать не “всё плохо”, а с контекстом: какой маршрут, какой статус, сколько ретраев, где именно стопор. Ловим 5xx на ровном месте до того, как клиент начнёт писать в саппорт.