Падение вебхука не видно глазами. Его ловят метрикой, а не надеждой

Падение вебхука не видно глазами. Его ловят метрикой, а не надеждой

Мониторинг эндпоинта — это не «пинг раз в минуту», а контроль цепочки: DNS, TLS, ответ приложения, код статуса, время обработки, размер тела и наличие ожидаемых полей. Если проверяете только 200 OK, ловите ложное спокойствие: сервис может отвечать 200 с пустой полезной нагрузкой и уже тихо ломать пайплайн.

Минимальный healthcheck должен присылать не просто статус, а сигналы для разборки: latency, payload_hash, request_id, upstream_status. Идемпотентность — это не роскошь, а база: алерт должен повторяться без дублей, а сам хендлер — уметь пережить повторную доставку. Если endpoint упал, алерт уходит в отдельную очередь, а не в тот же канал, который уже задыхается.

Практика простая:
— проверка с разных точек, чтобы отличить локальный флап от реального падения;
— два порога: warning на рост задержки, critical на ошибку или таймаут;
— отдельный алерт на отсутствие событий, а не только на 5xx;
— журналируйте сырой ответ, но без секретов и токенов. Смотрим в тело запроса, а не в красивые дашборды.

Финал: если мониторинг не умеет сказать, что именно сломалось и сколько раз это повторилось, он не мониторинг, а шум.