История проверок

Как читать историю проверок сайта, API, Cron и SSL

История запусков показывает каждый фактический результат мониторинга. Научитесь отличать сетевой сбой от таймаута, HTTP-ошибки, несовпадения JSON, проблемы настройки и ошибки SSL.

Создать аккаунт Открыть материалы

История проверок сайта, API, Cron и SSL в UpWatch

Краткий ответ

История проверок — это лента отдельных запусков монитора. Для каждого запуска отображаются время, успешный или неуспешный статус, задержка, HTTP-код, причина сбоя и текст произошедшего. Состав полей зависит от вида монитора.

Фильтры позволяют переключаться между проверками и сгруппированными инцидентами, выбирать успешные или неуспешные запуски, причину сбоя и — для HTTP-мониторов с JSON-правилами — ошибку ответа или ошибку настройки.

Для диагностики сначала найдите первый неуспешный запуск, затем сравните его с предыдущим успешным и следующими результатами. Один запуск показывает симптом в конкретный момент, а последовательность помогает понять динамику проблемы.

Почему текущего статуса монитора недостаточно

Зелёный или красный статус отвечает только на вопрос «что сейчас». История нужна, чтобы понять «что происходило».

Последняя проверка скрывает предыдущую деградацию

После восстановления текущий статус снова зелёный, но без истории невозможно оценить длительность и характер сбоя.

Одинаковая ошибка требует разных действий

Неуспешный запуск может быть вызван сетью, таймаутом, HTTP-кодом, JSON, конфигурацией или SSL. Статуса failure недостаточно.

HTTP 200 не всегда означает исправность

Ответ может иметь корректный код, но не пройти JSON-проверку по содержимому.

Одна строка не показывает динамику

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

Как формируется запись запуска

Запуск проходит путь от запланированного момента до фактического результата и сохраняет доступные технические поля.

Этап 1

Проверка получает запланированное время

Для плановых HTTP- и SSL-мониторов scheduler сохраняет исходную временную сетку в planned_at.

planned_at отражает план, а не момент начала сетевого запроса.
started_at показывает фактический старт выполнения.
created_at используется как резервная временная метка в интерфейсе.
Небольшая разница между планом и стартом возможна из-за polling, очереди и среды выполнения.

Этап 2

Worker выполняет профильную проверку

Набор действий зависит от HTTP, heartbeat или SSL-монитора.

HTTP: запрос, статус, задержка и при необходимости JSON-правила.
Heartbeat: успешный запуск создаётся при ping, ошибка — при превышении timeout.
SSL: TCP, TLS, сертификат, hostname, цепочка, срок действия и задержка.
Внутренние логи проверяемого сервиса не читаются.

Этап 3

Результат получает статус и причину

Успешный запуск сохраняется без причины сбоя, неуспешный получает failure_kind и текст ошибки.

network — сетевая доступность.
timeout — превышение времени ожидания.
http_status — неожиданный HTTP-код.
invalid_json, json_mismatch и config_error — JSON или настройка.
ssl_tls, ssl_certificate, ssl_expiring и ssl_expired — SSL/TLS.

Этап 4

Запуск попадает в историю и может изменить инцидент

Неуспешная проверка открывает или продолжает инцидент, успешная — может зафиксировать восстановление.

История хранит отдельные запуски.
Режим «Инциденты» показывает группировку ошибок.
Из карточки инцидента можно открыть ограниченный временной диапазон запусков.
Срок хранения истории зависит от тарифа.

Примеры чтения истории

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

HTTP 500 при обычной задержке

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

Таймаут с ростом задержки перед ошибкой

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

JSON mismatch при HTTP 200

Откройте детали правил и сравните expected с actual. Проверьте, изменился ли контракт или бизнес-состояние действительно неверно.

SSL certificate или SSL expired

Проверьте домен, порт, срок действия, издателя и субъект. После замены сертификата убедитесь, что новый запуск видит обновлённый сертификат.

Поля истории запусков

Не все поля применимы к каждому виду монитора. Прочерк означает отсутствие подходящих данных, а не обязательную ошибку.

Поле	Где используется	Что показывает	Как интерпретировать
Время	Все мониторы	В интерфейсе используется started_at, а при его отсутствии created_at.	Это фактическое или резервное время записи, а не всегда точный planned_at.
planned_at	Плановые проверки	Расчётный момент запуска по временной сетке.	Используйте для анализа отклонения расписания, если поле доступно в технических данных.
started_at	Все выполненные запуски	Момент фактического начала проверки.	Сравнивайте с planned_at, когда анализируете задержку очереди, а не latency сервиса.
Статус	Все мониторы	Успех или ошибка конкретного запуска.	Не заменяет failure_kind и технические детали.
Задержка, мс	HTTP и SSL	Время выполнения соответствующей внешней проверки.	Рост задержки может быть признаком деградации, но не объясняет её причину.
HTTP	HTTP-мониторы	Фактический код ответа.	Код может отсутствовать при сетевой ошибке или таймауте.
failure_kind	Неуспешные запуски	Классифицированная причина сбоя.	Используйте как направление диагностики, а не окончательную первопричину.
Текст ошибки	Неуспешные запуски	Конкретное описание полученного результата.	Сопоставляйте с причиной и настройками монитора.
JSON expected/actual	HTTP с JSON-правилами	Ожидаемое и фактическое значение не прошедшего правила.	Различайте ошибку ответа и ошибку настройки пути или операции.
SSL-детали	SSL-мониторы	Хост, порт, срок, оставшиеся дни, издатель и субъект.	Проверяйте, какой сертификат реально отдаёт сервер.
Heartbeat ping	Cron/heartbeat	Успешный запуск при ping или ошибка после timeout.	UpWatch подтверждает получение сигнала, но не знает внутренний результат задачи без корректной логики отправки ping.

Как диагностировать конкретный запуск

Двигайтесь от общего статуса к конкретной причине и только затем к внутренним системам.

Шаг 1

Выберите режим «Проверки»

Он показывает отдельные запуски, а не сгруппированные инциденты.

Сбросьте лишние фильтры.
Убедитесь, что смотрите нужный монитор.
Проверьте размер страницы и пагинацию.
При переходе из инцидента учитывайте выбранный диапазон.

Шаг 2

Найдите первый сбой

Первый неуспешный запуск лучше показывает момент изменения, чем последняя ошибка.

Отфильтруйте статус «Ошибка».
При необходимости выберите причину.
Вернитесь к предыдущему успешному запуску.
Сравните время и задержку.

Шаг 3

Прочитайте failure_kind и текст ошибки

Эти поля определяют первую ветку диагностики.

network — DNS, TLS, маршрутизация и доступность.
timeout — медленный сервис или слишком строгий таймаут.
http_status — фактический код и ожидаемая конфигурация.
config_error — сначала исправьте монитор, а не сервис.

Шаг 4

Откройте профильные детали

Для JSON и SSL общей строки недостаточно.

Для JSON нажмите кнопку деталей.
Сравните expected и actual.
Для SSL проверьте срок, домен, издателя и субъект.
Для heartbeat проверьте логику отправки ping после успешной задачи.

Шаг 5

Сравните соседние запуски

Последовательность показывает, разовый это сбой или устойчивая деградация.

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

Шаг 6

Подтвердите причину внутри системы

Внешняя история задаёт время и симптом, но не заменяет внутреннюю диагностику.

Откройте логи за точный период.
Проверьте метрики приложения, БД и инфраструктуры.
Сопоставьте релизы и изменения конфигурации.
Проведите безопасную ручную проверку сценария.

Что означает причина сбоя

Фильтр «Причина» использует те же значения, которые сохраняются в failure_kind.

Симптом	Возможная причина	Что делать
Сеть	DNS, отказ соединения, TLS на HTTP-запросе, маршрутизация, фаервол или недоступный адрес.	Проверьте разрешение домена, доступность порта и сетевые ограничения.
Таймаут	Сервис не завершил ответ за настроенное время.	Сравните задержку соседних запусков, нагрузку и значение таймаута.
HTTP статус	Сервер ответил кодом, который не соответствует ожидаемому.	Проверьте код, маршрут, авторизацию, прокси и серверные логи.
Невалидный JSON	Ответ оказался HTML, текстом, пустым телом или повреждённым JSON.	Проверьте фактическое тело ответа и Content-Type.
Несоответствие JSON	Правило корректно, но фактическое значение не совпало с ожидаемым.	Откройте детали и сравните expected, actual, путь и типы значений.
Ошибка настройки	Некорректный путь, операция или ожидаемое значение JSON-правила.	Исправьте конфигурацию монитора и проверьте следующий запуск.
TLS-соединение	Не удалось установить TLS на указанном хосте и порту.	Проверьте порт, протокол, SNI и TLS-настройки сервера.
SSL-сертификат	Проблема hostname, цепочки доверия или самого сертификата.	Проверьте сертификат, цепочку и соответствие домену.
SSL скоро истекает	Оставшийся срок достиг warning или critical порога.	Продлите сертификат и проверьте, что новый уже установлен.
SSL истёк	Срок действия сертификата закончился.	Срочно замените сертификат и подтвердите новый успешный запуск.

Как пользоваться фильтрами без потери контекста

Фильтр ускоряет поиск, но может скрыть соседние события, необходимые для правильного вывода.

Начинайте со всех запусков

Сначала оцените общую последовательность, затем сужайте выборку.

Статус отделяет успехи от ошибок

После поиска ошибки верните успешные запуски, чтобы увидеть границы деградации.

Причина ищет конкретный класс сбоя

Используйте её для повторяющихся timeout, HTTP, JSON или SSL-проблем.

Тип ошибки нужен для JSON

Фильтр «Ошибка ответа» и «Ошибка настройки» доступен только для HTTP-мониторов с JSON-проверками.

Режим «Инциденты» меняет представление

Он группирует ошибки и фиксирует статус failure, поэтому не равен обычному фильтру списка запусков.

Диапазон из инцидента временный

При переходе из карточки инцидента история ограничивается его началом и окончанием или последней ошибкой; диапазон можно сбросить.

Что доступно в истории UpWatch

Интерфейс показывает человеческую сводку и технические детали, не загружая тяжёлые JSON-данные для всех строк сразу.

Список запусков

Успешные и неуспешные проверки с пагинацией и размером страницы.

Фильтры

Статус, причина, режим проверок или инцидентов и тип JSON-ошибки, когда он применим.

HTTP и задержка

В строке запуска видны код ответа и latency, если они были получены.

JSON-детали по запросу

Expected и actual загружаются отдельно после открытия деталей конкретного запуска.

SSL-поля

Для SSL отображаются оставшиеся дни и расширенные сведения о сертификате.

Связь с инцидентами

Можно перейти от отдельных запусков к сгруппированным эпизодам и обратно.

Ограничения

История показывает результат внешней проверки, а не внутреннюю трассировку запроса.
HTTP-код отсутствует, если ответ не был получен.
Задержка проверки не равна времени всех внутренних операций приложения.
В интерфейсе основной столбец времени использует started_at, а при его отсутствии created_at.
Общий календарный фильтр по датам в текущем интерфейсе не представлен; диапазон передаётся при переходе из инцидента.
Детали JSON загружаются отдельно и доступны только для подходящих запусков.
Полученный heartbeat ping подтверждает сигнал, но не доказывает бизнес-успех задачи, если ping отправляется неправильно.
Срок хранения истории зависит от тарифа: FREE — 24 часа, PRO — 30 дней, TEAM — 90 дней.

Частые вопросы

Какое время показывается в списке запусков?

Используется started_at, а если оно отсутствует — created_at. planned_at доступен как отдельное техническое поле данных запуска.

Почему у ошибки нет HTTP-кода?

При сетевой проблеме или таймауте сервер мог не вернуть HTTP-ответ.

Почему HTTP 200 отмечен как ошибка?

Могла не пройти JSON-проверка содержимого ответа.

Чем ошибка ответа JSON отличается от ошибки настройки?

Ошибка ответа означает несовпадение корректного правила с фактическим JSON. Ошибка настройки означает проблему пути, операции или ожидаемого значения.

Можно ли отфильтровать SSL-проблемы?

Да. Доступны причины TLS-соединения, SSL-сертификата, скорого истечения и истёкшего сертификата.

Почему история ограничена?

Глубина хранения зависит от тарифа рабочего пространства.

Связанные материалы

Дополнительные руководства помогут связать настройку с API, историей запусков, инцидентами и уведомлениями.

Управление инцидентами

Посмотрите, как отдельные ошибки объединяются до успешного восстановления.

JSON-проверки API

Разберите пути, операции, expected/actual и причины ошибок JSON.

Мониторинг Cron и фоновых задач

Поймите, как ping и timeout формируют историю heartbeat-монитора.

Мониторинг SSL-сертификата

Настройте пороги срока действия и диагностику TLS и сертификатов.

Сохраняйте историю каждого запуска

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

Создать аккаунт Открыть справочный центр