Главное за минуту
- Журнал фиксирует действия и системные события, но не заменяет серверные логи.
- Для поиска нужны точное время, URL, пользователь и повторяемый сценарий сбоя.
- Сохраняйте фильтр и идентификаторы записи до очистки или обновления системы.
- При приёмке повторите сценарий и убедитесь, что новая ошибка не появляется.
01
Когда журнал событий помогает
Журнал событий Битрикс — это отправная точка, когда форма не отправилась, сотрудник потерял доступ, заказ изменился не тем пользователем или интеграция отработала с ошибкой. Он отвечает на вопрос «что произошло и когда», а не всегда на вопрос «почему упал код».
Откройте административную часть и журнал событий, затем отфильтруйте записи вокруг времени инцидента. Сначала фиксируйте факт: действие, URL, учётную запись, IP при необходимости и текст события. Не очищайте записи до передачи задачи: после очистки разработчик будет восстанавливать картину по косвенным данным.
02
Карточка инцидента
Четыре поля превращают жалобу в проверяемую задачу для поддержки.
03
Как искать ошибку в журнале событий Битрикс
Возьмите интервал в 10–15 минут до и после сбоя. Широкий период создаёт шум, а поиск только по слову «ошибка» пропускает отказы доступа и неудачные действия модулей.
Время и часовой пояс
Запишите время с минутами и уточните, в каком часовом поясе его назвал пользователь. Сверьте его с часовым поясом сервера и CRM.
Тип и источник
Ищите события авторизации, прав доступа, изменения элементов, почты и модулей. Источник часто указывает, где продолжать диагностику.
Контекст запроса
Добавьте URL, ID заказа или элемента, e-mail в маскированном виде и UTM. Это позволяет связать запись с конкретной заявкой или сессией.
04
Что означает запись и что делать дальше
Сама запись не равна диагнозу. Она показывает слой, на котором проявился сбой. Сопоставьте её с действиями пользователя, данными формы и результатом в CRM. Если событие относится к авторизации или правам, не меняйте доступы «наугад»: можно открыть закрытые разделы или скрыть следы причины.
| Признак | Проверить | Действие |
|---|---|---|
| Отказ в доступе | Группу, роль, права папки или инфоблока | Передать ID пользователя и URL; проверить под тестовой учётной записью |
| Форма без заявки | Время отправки, e-mail, UTM, почтовое событие и CRM | Сравнить запись с лидом или сделкой и серверным логом |
| Ошибка обмена | ID сущности, очередь, ответ API и повтор запуска | Не перезапускать обмен массово до резервной копии и оценки дублей |
| Подозрительное действие | Учётную запись, IP, время и изменение прав | Сменить пароль, завершить сессии и проверить настройки безопасности |
05
Что написать разработчику
Передавайте не скрин «что-то сломалось», а воспроизводимый инцидент. Скриншот допустим как дополнение, но ключевыми остаются время, условия и ожидаемый результат.
Готовое сообщение
Проблема: 12 мая в 14:32 пользователь не смог отправить форму на странице /checkout/.
Сценарий: открыть страницу, заполнить обязательные поля, выбрать доставку, нажать «Оформить». Ошибка повторяется в Chrome и на мобильном устройстве.
Ожидание: создаётся заказ и сделка в CRM; сохраняются источник, UTM-метки и состав корзины.
Данные: журнал событий за 14:20–14:40 приложен; URL, ID пользователя и тестовый e-mail переданы отдельно. Просим проверить модуль формы, почту, обмен с CRM и серверный error_log.
Приёмка: три тестовые отправки создают по одной сущности без дублей, событие ошибки не появляется, UTM доступны в CRM.
06
Порядок проверки после исправления
Попросите исполнителя описать, что изменено и какие логи просмотрены. Затем проверьте не только исчезновение ошибки, но и бизнес-результат: заказ, лид, уведомление или доступ сотрудника.
- 1Зафиксируйте исходную запись и экспортируйте данные инцидента.
- 2Создайте тестовые данные, не используя реальный заказ или клиента.
- 3Повторите исходный сценарий в том же браузере и на мобильном устройстве.
- 4Проверьте результат в Битрикс, почте и CRM, включая поля UTM.
- 5Откройте журнал повторно: новой записи с ошибкой быть не должно.
07
Когда журнала недостаточно
Журнал не хранит полный стек PHP-ошибки, SQL-запрос или ответ внешнего API. Для сложного случая разработчику нужны серверные логи, настройки PHP, данные очереди и безопасная копия запроса. Официальные материалы по инструментам разработки доступны в документации 1С-Битрикс.
Достаточно журнала
время + тип события + URL + ID сущностиНужна расширенная диагностика
HTTP-код + error_log + API-ответ + шаги воспроизведения08
Регламент для маркетинга и поддержки
Назначьте ответственного за первичную фиксацию инцидентов и храните шаблон задачи в рабочем пространстве. Для критичных форм и оплат проверяйте журнал после обновлений, рекламных запусков и изменений интеграций. Подходящие примеры процессов и реализации можно сверить с портфолио ICONICA.
Точное время инцидента; URL и шаги пользователя; ID заказа, лида или элемента; пользователь и роль; запись из журнала; ожидаемый результат; проверка в CRM; повторная проверка журнала.
FAQ
Частые вопросы
Где находится журнал событий?
В административной части сайта, в разделе настроек и инструментов. Название пункта зависит от версии и настроек продукта.
Можно ли удалить записи после исправления?
Да, но только после приёмки и при наличии согласованного срока хранения. Для расследования старые записи важны.
Почему в журнале нет ошибки PHP?
Критическая ошибка могла попасть только в серверный error_log. Передайте поддержку точное время и сценарий.
Нужно ли давать маркетологу доступ к админке?
Достаточно ограниченного доступа на просмотр либо регламента, по которому выгрузку делает ответственный сотрудник.
