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

Если эндпоинт молчит, первая ошибка — смотреть только на 200 OK. Нужен отдельный health-check, который бьет в тот же хендлер с тестовой полезной нагрузкой и проверяет не только код ответа, но и время обработки, структуру ответа и побочные эффекты. Идемпотентность — это не роскошь, а база: проверочный запрос не должен создавать дубль в очереди или писать мусор в БД.

Алерт строится не на одном падении, а на серии симптомов: таймауты, рост 5xx, увеличение p95/p99, всплеск ретраев. Если триггерить тревогу на один фейл, вы получите сирену на ровном месте. Если молчать до полного обвала — получите постмортем вместо реакции. Ретрай-политика решает всё: экспоненциальная задержка, лимит попыток, отдельный dead-letter для мусорных событий.

Пишите метрики по каждому этапу: принял запрос, провалидировал, поставил в очередь, обработал, заквитал. Тогда видно, где именно течет пайплайн. Пример полезной схемы: webhook_received=1, webhook_validated=1, queue_enqueued=1, handler_ok=1. Если первый счетчик растет, а последний стоит — ловим 5xx на ровном месте и уже не гадаем.

Не забывайте про внешний слой: IP-whitelist, секрет в заголовке, HMAC-подпись, короткий timeout у клиента и отдельный алерт на отказ DNS/сети. Мониторинг без проверки доставки — это декоративная панель, а не контроль системы.

Смотрим в тело запроса, считаем таймауты, проверяем очередь и шлем алерт только тогда, когда симптом подтвержден повторно.