Если endpoint не отвечает, уходит в таймаут или недоступен только для части клиентов, проблему нужно искать последовательно: от DNS и соединения до прокси, приложения и его зависимостей.
API считается недоступным, когда клиент не может получить ожидаемый ответ от нужного endpoint-а. Это может проявляться как ошибка DNS, отказ соединения, проблема TLS, таймаут, HTTP-ошибка или неожиданное закрытие соединения.
Сайт при этом может продолжать открываться. Например, статическая главная страница загружается через CDN, а авторизация, личный кабинет, оплата или мобильное приложение уже не работают из-за недоступности API.
Проблема может затрагивать весь API, отдельный домен, один маршрут, конкретный HTTP-метод или только часть пользователей. Поэтому недостаточно проверить один произвольный URL и сделать вывод о состоянии всей системы.
Важно определить последний уровень, до которого запрос проходит успешно. Если имя домена не разрешается, до приложения запрос вообще не доходит. Если соединение устанавливается, но ответ не приходит, нужно проверять прокси, приложение, базу данных и внешние зависимости.
Внешний мониторинг фиксирует пользовательский результат: доступен ли endpoint, сколько занял запрос, вернулся ли HTTP-статус и когда работа восстановилась. Внутреннюю причину нужно сопоставлять с логами и метриками инфраструктуры.
Запишите URL, HTTP-метод, время ошибки, заголовки и ожидаемый результат. Убедитесь, что проверяется именно проблемный endpoint, а не соседний служебный маршрут.
Убедитесь, что домен разрешается в ожидаемый адрес и не осталась устаревшая запись после переноса, изменения балансировщика или переключения инфраструктуры.
Определите, устанавливается ли соединение с нужным портом и проходит ли TLS. Ошибка сертификата, несовпадение имени или проблема протокола делают API недоступным ещё до HTTP-запроса.
Сверьте маршрут, домен, префикс API, правила ingress или reverse proxy и наличие доступных экземпляров приложения за балансировщиком.
Посмотрите, принимает ли процесс запросы, не перезапускается ли он и нет ли в логах исключений, зависаний или исчерпания рабочих процессов.
API может не отвечать из-за базы данных, Redis, очереди, хранилища или внешнего сервиса. Сопоставьте время недоступности с состоянием этих компонентов.
Проверьте healthcheck, авторизацию и бизнес-маршрут отдельно. Успешный служебный ответ не гарантирует, что endpoint с обращением к базе данных действительно работает.
Проверьте релизы, миграции, настройки DNS, сертификаты, правила прокси и изменения сетевой политики, выполненные перед началом проблемы.
Если домен не разрешается, проблема находится на уровне DNS или используемого DNS-резолвера. Нужно проверить записи, срок их действия, делегирование домена и недавние изменения адресов.
Если DNS работает, но соединение отклоняется, проверьте правильность порта, работу процесса, сетевые правила, firewall, балансировщик и наличие маршрута до приложения.
Если соединение устанавливается, но TLS завершается ошибкой, проверьте срок действия сертификата, соответствие домену, цепочку доверия и конфигурацию HTTPS на прокси.
Если запрос уходит в таймаут, это не всегда означает полную недоступность сервера. Приложение могло принять запрос, но зависнуть при обращении к базе данных, внешнему API, очереди или файловому хранилищу.
Если прокси возвращает 502, он обычно не получил корректный ответ от приложения. При 503 сервис или балансировщик может сообщать, что сейчас нет готовых экземпляров или система временно не принимает запросы.
Если API возвращает 500, запрос дошёл до приложения, но его обработка завершилась внутренней ошибкой. Такой случай относится уже не к сетевой недоступности, а к ошибке выполнения.
Если один endpoint работает, а другой нет, проверяйте различия в маршрутах, правах доступа, коде обработчика и используемых зависимостях. Общий healthcheck может не обращаться к базе данных и поэтому оставаться успешным.
Если API работает из внутренней сети, но недоступен снаружи, вероятная область поиска — публичный DNS, ingress, reverse proxy, firewall, WAF или маршрутизация.
Если проблема возникает только у части клиентов, сравните сети, регионы, версии приложений, используемые домены, авторизацию и параметры запроса. Это может быть частичная, а не полная недоступность.
После восстановления проверьте не только служебный endpoint, но и реальные пользовательские маршруты. Один успешный healthcheck не доказывает исправность авторизации, оплаты или операций с данными.
При плавающей проблеме ручной запрос может попасть в удачный промежуток. История регулярных проверок помогает увидеть повторяемость и сопоставить её с нагрузкой, перезапусками и инфраструктурными событиями.
UpWatch не подключается к внутренним логам и не определяет причину автоматически. Он фиксирует внешний симптом, время сбоя и восстановление, а диагностические выводы нужно подтверждать данными приложения и инфраструктуры.
Сайт и API могут обслуживаться разными доменами, прокси, приложениями и инфраструктурой. Статическая страница может загружаться через CDN, пока backend, база данных или отдельный API-домен уже недоступны.
При недоступности клиент может вообще не получить HTTP-ответ из-за DNS, соединения, TLS или таймаута. Ошибка API обычно означает, что ответ получен, но его статус или содержимое не соответствуют ожидаемому результату.
Простой healthcheck может проверять только запуск процесса. Бизнес-endpoint дополнительно обращается к базе данных, очередям, хранилищу и другим сервисам, один из которых может быть недоступен.
Клиент не получил полный ответ за установленное время. Причиной может быть сеть, перегрузка, зависание приложения, медленная база данных или внешняя зависимость.
Если внутренний запрос работает, а публичный нет, нужно проверять внешний DNS, балансировщик, ingress, reverse proxy, WAF, firewall и публичную маршрутизацию.
Причина может зависеть от сети, региона, DNS-резолвера, версии клиента, авторизации, конкретных данных или попадания запросов на разные экземпляры приложения.
Да. Причиной могут быть неприменённые миграции, неверная конфигурация, изменение маршрута, несовместимость версий, отсутствие готовых экземпляров или ошибка нового кода.
Да. В HTTP-мониторе UpWatch можно настраивать метод запроса и параметры проверки.
Для обычной HTTP-проверки успешный статус означает успешный HTTP-ответ. Чтобы контролировать ожидаемые данные, нужно дополнительно использовать JSON-проверку содержимого.
Нет. UpWatch фиксирует внешний результат проверки, ошибку, таймаут, длительность, историю запусков и восстановление. Причину нужно искать в логах, метриках и конфигурации инфраструктуры.
В первую очередь авторизацию, профиль пользователя, заказ, оплату, критичные интеграции и публичные API. Служебный healthcheck полезен, но его недостаточно для контроля бизнес-функций.
Как настроить регулярные HTTP-проверки endpoint-ов, методов, статусов и таймаутов.
Как разбирать HTTP-ошибки, если endpoint отвечает, но возвращает неуспешный статус.
Как контролировать ожидаемые поля и значения, если одного HTTP-статуса недостаточно.
Почему прокси не может получить корректный ответ от приложения.
Почему сервис может временно не принимать запросы.
Как искать внутреннюю ошибку приложения, базы данных или конфигурации.
