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