В «Контроле сайта» проверка доступности запланирована раз в пять минут. Она показывает ответ сайта на отдельный запрос, а не состояние каждой секунды между запросами. Короткий сбой может начаться и закончиться до следующей проверки.
Поэтому сообщение посетителя о проблеме и два успешных результата мониторинга могут одновременно быть верными. Для разбора сохраните адрес и время попытки посетителя, затем сравните их с фактически выполненными проверками.
Посмотрите на двухминутный сбой между запросами
Допустим, сервис обратился к странице в 10:00 и 10:05. Между этими запросами произошёл короткий отказ:
| Время | Что происходило с сайтом | Что попало в проверку |
|---|---|---|
| 10:00 | Страница открывается | Успешный ответ |
| 10:02 | Начался сбой | Запроса в эту минуту нет |
| 10:03 | Посетитель получил ошибку | Есть сообщение посетителя |
| 10:04 | Сайт снова отвечает | Запроса в эту минуту нет |
| 10:05 | Страница открывается | Успешный ответ |
Это учебная шкала. Она объясняет ограничение периодических запросов, а не обещает точное время запуска каждой реальной проверки. По двум успешным ответам нельзя заключить, что посетитель ошибся.
В такой ситуации попросите его назвать точный адрес и примерное время, сохранить сообщение ошибки. Передайте интервал разработчику или хостингу для проверки серверных записей — логов. В руководстве по мониторингу подробнее разобрано назначение проверок доступности.
Не называйте время обнаружения точным началом сбоя
Если в 10:00 сайт ответил, а в 10:05 проверка показала проблему, известно состояние в эти два момента. Когда именно между ними возник сбой, из этих данных не видно.
Первый успешный ответ после проблемы тоже не устанавливает точную минуту восстановления: сайт мог начать работать раньше. В отчёте лучше написать «проверка в 10:05 показала ошибку, в 10:10 получен нормальный ответ», чем «сайт не работал ровно пять минут».
Если специалист уточнил начало и конец по логам, добавьте источник и часовой пояс. Например: «Мониторинг заметил ошибку в 10:05 МСК; по журналу сервера отказ начался в 10:03». Не заменяйте одну отметку другой: они отвечают на разные вопросы.
Проверяйте реальные даты, особенно при пропуске данных
Пять минут — плановая частота, а не гарантия своевременного выполнения каждого запроса. Отдельная проверка может задержаться или не дать результата. Условия подписки «Контроль сайта» не следует превращать в обещание непрерывного наблюдения.
Если последний результат старый, не считайте сайт доступным всё это время по прежнему зелёному статусу. Сначала откройте адрес вручную, посмотрите следующую завершённую проверку и уточните, почему нет свежих данных.
В записи разделите три случая: «получен нормальный ответ», «получена ошибка» и «нового результата нет». Последний случай не подтверждает ни исправную работу, ни текущую недоступность. Так отчёт не будет скрывать неизвестный период.
Для повторяющихся коротких проблем собирайте второй источник
Записывайте жалобы с адресом, временем, устройством и точным действием. Если проблема случается только при отправке формы, одного открытия главной недостаточно. В статье о неработающем заказе есть порядок проверки такого пути.
Для обращения хостингу полезен короткий текст: «Посетители сообщили об ошибке /catalog в 10:03 и 12:18 МСК. В ближайших проверках мониторинга успешные ответы. Просим проверить этот адрес и интервалы по логам». Если время приблизительное, так и укажите.
Сопоставляйте сведения, сохраняя различия. Мониторинг проверял публичный адрес, посетитель нажимал кнопку, журнал сервера мог записывать другой этап. Совпадение минут само по себе ещё не объясняет причину. Результатом разбора должны стать конкретный подтверждённый случай или честно записанные сведения, которых пока не хватает.