b_event в 1С-Битрикс: как очистить очередь почты

If the table b_event растёт, а письма из 1С-Битрикс не уходят или приходят с большой задержкой, не начинайте с TRUNCATE TABLE b_event. Сначала остановите обработку очереди на время диагностики, сделайте резервную копию, проверьте статусы событий и отделите действительно устаревшие письма от актуальных.

Короткий порядок действий:

1. Посчитать события по SUCCESS_EXEC и посмотреть самые старые записи.
2. Проверить почтовые шаблоны, агенты или cron и серверный почтовый транспорт.
3. Сделать резервную копию базы либо выбранных строк b_event.
4. Удалять только проверенные события: по ID, типу события и дате.
5. После исправления причины включить обработку и убедиться, что очередь уменьшается.

Ниже — безопасная инструкция для администраторов и разработчиков. Все запросы сначала выполняйте как SELECT. Команды DELETE допустимы только после проверки выборки и резервного копирования.

Что хранится в b_event

Method CEvent::Send и его D7-аналог Bitrix\Main\Mail\Event::send регистрируют почтовое событие для последующей отправки. Запись попадает в b_event, а затем обрабатывается механизмом почтовых событий.

У старого API есть метод CEvent::CheckEvents: по официальной документации он собирает неотправленные события и передаёт письма функции bxmail. В актуальных версиях главного модуля агенты и почтовые события могут выполняться как фоновые задания, а на боевых проектах их обычно запускают по cron.

Есть и немедленная отправка через CEvent::SendImmediate or Bitrix\Main\Mail\Event::sendImmediate. Она не создаёт запись в b_event, но это не универсальная замена очереди: SMTP-задержка в таком случае влияет на время выполнения текущего запроса.

Что означает SUCCESS_EXEC

Значение поля нужно оценивать вместе с DATE_INSERT, DATE_EXEC, типом события и почтовыми логами.

Статус	Что обычно означает	Что проверять
N	Результата отправки ещё нет	Работает ли обработчик событий, cron и фоновые задания
Y	Механизм отправки вернул успешный результат	Логи MTA/SMTP и доставку до сервера получателя
F	Отправка завершилась ошибкой	sendmail_path, SMTP, права пользователя cron и журналы ошибок
P	Выполнена только часть отправок	Несколько шаблонов или получателей одного события
0	Не найден подходящий почтовый шаблон	Активность шаблона, его тип, сайт и язык

В старых инструкциях встречается SUCCESS_EXEC = 'E', но в официальном наборе результатов отправки используется F для ошибки. Учитывайте версию ядра и перед удалением посмотрите реальные значения в своей базе.

Important: Y не гарантирует попадание письма во «Входящие». Этот статус показывает результат передачи на настроенный почтовый механизм. Финальную доставку подтверждают журналы SMTP-провайдера или MTA, а не только b_event.

Как проверить очередь до очистки

Откройте Settings -> Tools -> SQL Query либо подключитесь к базе с учётной записью, имеющей минимально необходимые права.

Сначала узнайте распределение событий по статусам:

SELECT SUCCESS_EXEC, COUNT(*) AS event_count
FROM b_event
GROUP BY SUCCESS_EXEC
ORDER BY event_count DESC;

Затем проверьте последние записи и возраст очереди:

SELECT ID, EVENT_NAME, SUCCESS_EXEC, DATE_INSERT, DATE_EXEC
FROM b_event
ORDER BY ID DESC
LIMIT 100;

Отдельно посмотрите события, которые ещё не были обработаны:

SELECT ID, EVENT_NAME, SUCCESS_EXEC, DATE_INSERT
FROM b_event
WHERE SUCCESS_EXEC = 'N'
ORDER BY ID ASC
LIMIT 100;

Если количество N не уменьшается, проблема чаще всего находится не в самой таблице, а в запуске обработчика. Если записи переходят в F, обработчик работает, но почтовый транспорт возвращает ошибку.

Почему письма копятся в очереди

На практике встречаются пять основных сценариев:

1. Не запускаются агенты или фоновые задания. Ошибка в cron, неверный путь к PHP или отключённый обработчик оставляют события в N.
2. Cron работает под другим пользователем. CLI использует другие настройки PHP, sendmail_path, права на файлы или SMTP-конфигурацию.
3. Проблема с SMTP или локальным MTA. Истёк пароль, заблокирован порт, исчерпана квота, закончилось место на диске либо провайдер отклоняет отправителя.
4. Не найден почтовый шаблон. Шаблон выключен, не привязан к нужному сайту или не соответствует языку события.
5. Приложение создаёт события повторно. Обработчик формы, заказа или интеграции вызывается несколько раз, поэтому очередь исправна, но в ней появляются дубли.

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

Как безопасно остановить массовую отправку

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

1. Временно остановите именно то cron-задание, которое обрабатывает почтовые события. Не отключайте без необходимости весь cron сервера.
2. Зафиксируйте время остановки и число записей по каждому статусу.
3. Сделайте дамп базы или хотя бы экспорт строк, которые планируете удалить.
4. Согласуйте критерии устаревшего письма: дата, EVENT_NAME, ID и бизнес-сценарий.
5. После очистки исправьте SMTP или cron и только затем верните обработку очереди.

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

Как очистить b_event без удаления всей таблицы

Самый безопасный вариант — удалить заранее просмотренный список ID:

DELETE FROM b_event
WHERE ID IN (123, 124, 125);

Если событий много, сначала сформируйте узкую выборку. В примере ниже дата и тип события условные — замените их значениями своего проекта:

SELECT ID, EVENT_NAME, SUCCESS_EXEC, DATE_INSERT
FROM b_event
WHERE SUCCESS_EXEC IN ('N', 'F', '0')
  AND EVENT_NAME = 'SALE_NEW_ORDER'
  AND DATE_INSERT < '2026-08-01 00:00:00'
ORDER BY ID ASC
LIMIT 500;

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

DELETE FROM b_event
WHERE SUCCESS_EXEC IN ('N', 'F', '0')
  AND EVENT_NAME = 'SALE_NEW_ORDER'
  AND DATE_INSERT < '2026-08-01 00:00:00'
LIMIT 500;

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

Почему не стоит начинать с TRUNCATE

Команда ниже мгновенно очищает всю таблицу и не учитывает статус, дату или тип события:

TRUNCATE TABLE b_event;

Для штатного устранения задержек это слишком грубый инструмент. Вместе с устаревшими письмами исчезнут новые заявки, системные уведомления и данные, необходимые для разбора инцидента. TRUNCATE может быть оправдан только в заранее согласованной аварийной процедуре с актуальным бэкапом и пониманием последствий.

Как проверить cron и отправку почты

Официальная документация 1С-Битрикс приводит запуск обработчика через файл:

/bitrix/modules/main/tools/cron_events.php

Конкретная строка cron зависит от окружения. Важно проверить не только наличие задания, но и фактическое выполнение:

• путь к CLI-версии PHP и корню сайта;
• пользователя, под которым запускается PHP;
• совпадение критичных настроек CLI и веб-окружения;
• код завершения и stderr cron-команды;
• права на кеш, логи и временные каталоги;
• доступность SMTP из-под того же пользователя;
• уменьшение количества событий N после запуска.

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

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

Очередь или немедленная отправка: что выбрать

Для большинства бизнес-уведомлений очередь предпочтительнее: пользователь не ждёт ответа SMTP, а временная недоступность почтового сервера не ломает оформление заказа или отправку формы.

Немедленная отправка полезна только там, где команда осознанно принимает задержку внешнего сервиса:

use Bitrix\Main\Mail\Event;

Event::sendImmediate([
    'EVENT_NAME' => 'FORM_FEEDBACK',
    'LID' => 's1',
    'C_FIELDS' => [
        'EMAIL_TO' => 'manager@example.com',
        'NAME' => 'Иван',
    ],
]);

Не переводите все события на sendImmediate ради обхода неисправного cron. Это маскирует проблему и переносит зависимость от SMTP в пользовательский запрос.

Как не допустить повторного переполнения b_event

Добавьте в мониторинг четыре показателя:

• число событий N старше допустимого времени;
• возраст самого старого события N;
• число F and 0 за последний час;
• скорость появления и обработки новых записей.

Настройте уведомление до того, как очередь станет заметна пользователям. Для интернет-магазина также полезно разделять критичные транзакционные письма и маркетинговые рассылки, ограничивать повторные вызовы событий и хранить корреляционный ID заказа или заявки в логах приложения.

Если диагностика показывает системные проблемы с cron, SMTP, обновлениями ядра или кастомными обработчиками, нужен не очередной SQL-запрос, а аудит и сопровождение проекта на 1С-Битрикс.

FAQ

Можно ли удалить все записи из b_event

Технически можно, но для рабочего сайта это риск потери актуальных уведомлений и данных для диагностики. Безопаснее сделать резервную копию и удалить только проверенные записи по ID, типу события, статусу и дате.

Почему в b_event много записей со статусом N

Статус N означает, что итог отправки ещё не зафиксирован. Если старые записи долго не меняются, проверьте фоновые задания, cron и запуск cron_events.php. Если новые записи обрабатываются, но появляются быстрее, чем исчезают, ищите дублирующий код или недостаточную пропускную способность отправки.

Чем отличаются SUCCESS_EXEC N и F

N обычно означает ожидание обработки, а F — неуспешную попытку отправки. Для F смотрите SMTP/MTA-логи и настройки sendmail_path; для длительного N — механизм запуска почтовых событий.

Что означает SUCCESS_EXEC равный 0

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

Почему письмо не пришло, хотя SUCCESS_EXEC равен Y

Y не подтверждает доставку в почтовый ящик. Письмо могло быть принято локальным MTA или SMTP-шлюзом, а затем отклонено, возвращено или помещено в спам. Проверяйте журналы почтового сервиса, SPF, DKIM, DMARC и репутацию отправителя.

Нужно ли переносить почтовые события на cron

Для коммерческого проекта cron даёт предсказуемый запуск независимо от посещаемости. Настройку нужно выполнять по документации для вашей версии 1С-Битрикс и обязательно проверять права пользователя, CLI-конфигурацию PHP и журналы выполнения.

Useful on the topic

• Разработка и поддержка сайтов на 1С-Битрикс
• Как программно удалить заказ в 1С-Битрикс на D7
• 1С-Битрикс или WordPress: сравнение платформ
• Кейс: перенос корпоративного сайта РКС на 1С-Битрикс

Sources

• 1С-Битрикс: устройство почтовой системы и значения SUCCESS_EXEC
• 1С-Битрикс: CEvent::Send
• 1С-Битрикс: CEvent::CheckEvents
• 1С-Битрикс: CEvent::SendImmediate и коды результата
• 1С-Битрикс D7: Bitrix Main Mail Event::send
• 1С-Битрикс: запуск агентов из cron