Uptimely
Все материалы

Доступность

HTTP-мониторинг: коды ответа, редиректы и тайм-ауты

Как проверить HTTP-контракт, разобрать перенаправления и отличить timeout от медленного успешного ответа.

Команда Uptimely

HTTP-мониторинг проверяет конкретный адрес и ожидаемый ответ. Полученный код ещё не говорит, что страница правильная, а открывающаяся главная страница не подтверждает работу всех API. Начните с одного понятного контракта: что запрашиваем, каким методом, какой ответ нормален и сколько времени готовы ждать.

Сначала посмотрите ответ вручную

Подставьте публичный URL своего сервиса. Команда не создаёт монитор и показывает результат только из вашей сети.

curl --silent --show-error --output /dev/null \
  --connect-timeout 5 --max-time 15 \
  --write-out 'HTTP %{http_code}\nTTFB %{time_starttransfer}s\nTotal %{time_total}s\n' \
  https://example.com/

Здесь нет --fail: диагностике полезно показать и 401, и 404, и 500. Для постоянного монитора решающим остаётся сравнение с ожидаемым кодом, по умолчанию 200. Если ваш endpoint по контракту возвращает 204, настройте именно 204.

Отдельно разберите редиректы

Перенаправление может быть нормальным переходом на HTTPS, а может вести на страницу входа или чужой адрес. Чтобы увидеть конечный адрес при ручной проверке, используйте ограничение числа переходов:

curl --silent --show-error --location --max-redirs 5 \
  --connect-timeout 5 --max-time 15 --output /dev/null \
  --write-out 'Final %{url_effective}\nHTTP %{http_code}\nRedirects %{num_redirects}\n' \
  https://example.com/

Не переносите поведение этой команды на монитор автоматически: сопоставьте его настройки и фактическую диагностику. Для авторизованных запросов отдельно проверяйте назначения редиректов и не отправляйте секреты на посторонние хосты. Справка по параметрам доступна в документации curl .

Не путайте тайм-аут с медленным ответом

Тайм-аут ограничивает ожидание. При его превышении законченного ответа нет. Медленный успешный ответ — другой случай: HTTP-код получен, но длительность выше допустимой. Задавайте порог исходя из замеров и допустимого времени для клиента, а не из одного самого быстрого ручного запроса.

TTFB и полное время ответа тоже различаются. Время HTTP-запроса не измеряет выполнение JavaScript, появление кнопок или загрузку интерфейса целиком. Для этого нужны другие проверки.

Подключите постоянную проверку

  1. Откройте HTTP/HTTPS-мониторинг и создайте монитор нужного URL.
  2. Выберите метод, ожидаемый код, тайм-аут и допустимый интервал.
  3. Дождитесь первого результата, сравните адрес и код с контрактом.
  4. Настройте уведомления и проверьте правила подтверждения инцидента.

HTTP доступен на Free в пределах тарифных лимитов. Если проверка не проходит только из Uptimely, проверьте WAF, CDN и разрешение доступа для регионов проверок. Не отключайте защиту сайта ради успешного статуса.

Где заканчивается HTTP-монитор

Для неправильной страницы с кодом 200 подходит проверка текста. Для проверки цепочки после входа — API-сценарий. Если нужен набор проверок сайта, используйте мониторинг сайта, сохранив отдельные результаты каждого слоя.

На изолированном тестовом стенде измените ожидаемый ответ, проверьте ошибку и восстановление. Рабочие URL и данные для демонстрации отказа не меняйте. Параметры настройки описаны в документации HTTP.