Мониторинг вебхуков: что надо знать ДО того как лёг эндпоинт

Узнать о проблеме из письма партнёрской сети («ваш эндпоинт вернул 500 на последние 200 запросов») — худший вариант. К этому моменту данные уже потеряны или застряли в DLQ отправителя.

Метрики которые нужно мониторить:
- **Доступность**: простой /health эндпоинт, пинг каждые 30 секунд
- **Latency**: p50/p95/p99 времени ответа. Вебхук должен отвечать 200 быстро (< 2-3 сек), тяжёлую обработку — в очередь
- **Error rate**: % 4xx и 5xx ответов за скользящие 5 минут
- **Queue depth**: если обработка асинхронная — длина очереди и возраст старейшего сообщения
- **DLQ size**: должен быть ноль большую часть времени

Алерты: не «когда сервер лёг», а «когда error rate > 1% за 5 минут». Проактивно.

Практика: отдельный синтетический хук каждые 5 минут — ты сам себе шлёшь тестовое событие и проверяешь что оно прошло полный цикл. Это ловит тихие баги когда сервер жив, но логика внутри сломана.

Инструменты: Grafana + Prometheus, Datadog, или минимум UptimeRobot + собственные метрики в InfluxDB.