Skip to Content
HTTP

HTTP-проверка сайта или API

HTTP-монитор отвечает на простой вопрос: внешний клиент может получить ожидаемый ответ за приемлемое время?

Лучший кандидат для первой проверки - https://example.com/health или другой легкий endpoint, который быстро отвечает и не меняет данные.

Настройки

  • URL указывается вместе с протоколом: https://example.com/health.
  • Ожидаемый код ответа по умолчанию 200, но его можно изменить.
  • Метод, заголовки и тело запроса нужны для API-проверок.
  • Таймаут ограничивает максимальное время ожидания ответа.
  • Порог медленного ответа задается отдельно от ошибки доступности.

Для публичного сайта часто достаточно GET и ожидаемого кода 200. Для API иногда лучше проверять HEAD, POST с тестовым телом или endpoint, который возвращает 204. Если сервис требует авторизацию, используйте заголовок с тестовым токеном или отдельный диагностический endpoint.

Как понять результат

  • Код не совпал с ожидаемым - проверка не прошла.
  • Ответ не пришел до таймаута - timeout.
  • DNS, TCP или TLS не завершились - причина видна в диагностике.
  • Код успешный, но время выше порога - это деградация, а не полное падение.

Если вы видите ошибку только из Uptimely, проверьте allowlist. WAF, CDN или firewall могут блокировать внешние проверки по User-Agent или IP-адресу.

Практика

Лучший URL для мониторинга - отдельный health endpoint. Он должен быстро отвечать, не менять данные и проверять только то, что действительно нужно для доступности сервиса.

Не делайте health endpoint слишком умным. Если он проверяет базу, очередь, внешнюю оплату, аналитику и сторонний API одновременно, одна чужая проблема будет выглядеть как падение всего сервиса. Для таких зависимостей лучше завести отдельные мониторы или явно подписать компонент на странице статуса.

Примеры

Сайт: GET https://example.com -> 200
API health: GET https://api.example.com/health -> 204
Закрытый API: GET https://api.example.com/status с заголовком Authorization
Мониторинг APIHeartbeat