b_event in 1C-Bitrix: how to clear the mail queue

If the table b_event is growing, but letters from 1C-Bitrix do not leave or arrive with a long delay, don't start with TRUNCATE TABLE b_event. First, stop queue processing for diagnostic purposes, make a backup copy, check event statuses, and separate truly outdated messages from actual ones.

Short procedure:

1. Count events by SUCCESS_EXEC and see the oldest entries.
2. Check mail templates, agents or cron and server mail transport.
3. Make a backup copy of the database or selected rows b_event.
4. Delete only verified events: by ID, event type and date.
5. After correcting the cause, enable processing and make sure that the queue decreases.

Below are safe instructions for administrators and developers. First execute all queries as SELECT. Teams DELETE valid only after checking the selection and backup.

What is stored in b_event

Method CEvent::Send and its D7 analogue Bitrix\Main\Mail\Event::send register a mail event for subsequent sending. The entry goes to b_event, and then processed by the mail event engine.

The old API has a method CEvent::CheckEvents: according to the official documentation, it collects unsent events and passes letters to the function bxmail. In current versions of the main module, agents and mail events can be executed as background jobs, and on combat projects they are usually launched via cron.

There is also immediate delivery via CEvent::SendImmediate or Bitrix\Main\Mail\Event::sendImmediate. It does not create an entry in b_event, but this is not a universal replacement for a queue: the SMTP delay in this case affects the execution time of the current request.

What does SUCCESS_EXEC mean?

The field value must be evaluated together with DATE_INSERT, DATE_EXEC, event type and mail logs.

Status	What does it usually mean	What to check
N	There is no sending result yet	Is the event handler, cron and background jobs running?
Y	The submit mechanism returned a successful result	MTA/SMTP logs and delivery to the recipient server
F	Sending failed	sendmail_path, SMTP, cron user rights and error logs
P	Only part of the shipments completed	Multiple templates or recipients for one event
0	No suitable email template found	Template activity, its type, site and language

In old instructions it appears SUCCESS_EXEC = 'E', but the official submission result set uses F for an error. Take into account the kernel version and look at the real values ​​​​in your database before deleting.

Important: Y does not guarantee that the letter will be sent to your inbox. This status shows the result of the transfer to the configured mail engine. The final delivery is confirmed by the logs of the SMTP provider or MTA, and not only b_event.

How to check the queue before clearing

Open Settings -> Tools -> SQL Query or connect to the database with an account that has the minimum necessary rights.

First, find out the distribution of events by status:

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

Then check the latest entries and queue age:

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

Separately look at the events that have not yet been processed:

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

If quantity N does not decrease, the problem most often is not in the table itself, but in the launch of the handler. If records go to F, the handler works, but the mail transport returns an error.

Why do emails accumulate in the queue?

In practice, there are five main scenarios:

1. Agents or background jobs do not start. An error in cron, an invalid PHP path, or a disabled handler leaves events in N.
2. Cron is running under a different user. CLI uses different PHP settings, sendmail_path, file rights or SMTP configuration.
3. Problem with SMTP or local MTA. The password has expired, the port is blocked, the quota has been reached, the disk space has run out, or the provider is rejecting the sender.
4. Email template not found. The template is disabled, is not linked to the desired site, or does not match the event language.
5. The application recreates events. The form, order, or integration handler is called several times, so the queue is working fine, but duplicates appear in it.

Address the root cause first. Simply deleting rows will temporarily shrink the table, but the queue will grow again.

How to safely stop bulk sending

If users may be left with thousands of expired notifications after SMTP repair, proceed to the maintenance window:

1. Temporarily stop the cron job that processes mail events. Do not unnecessarily disable the entire cron server.
2. Record the stop time and the number of entries for each status.
3. Dump the database or at least export the rows you plan to delete.
4. Agree on the criteria for an outdated letter: date, EVENT_NAME,ID and business scenario.
5. After cleaning, fix SMTP or cron and only then return queue processing.

This way, new requests will not be mixed with the old tail, and the team will still have the opportunity to restore an erroneously deleted event.

How to clear b_event without deleting the entire table

The safest option is to remove the pre-viewed list of IDs:

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

If there are many events, form a narrow sample first. In the example below, the date and event type are conditional - replace them with the values of your project:

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;

Only if the selection actually contains stale events and the backup is ready, apply the same conditions to the deletion:

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;

Remove in small batches and monitor the remainder after each run. This reduces the load on the database and the risk of long-term blocking of a large table.

Why you shouldn't start with TRUNCATE

The command below instantly clears the entire table and does not take into account the status, date or event type:

TRUNCATE TABLE b_event;

For regular elimination of delays, this is too crude a tool. Along with outdated letters, new requests, system notifications and data necessary for analyzing the incident will disappear. TRUNCATE can only be justified in a pre-agreed emergency procedure with up-to-date backup and understanding of the consequences.

How to check cron and mail sending

The official 1C-Bitrix documentation shows how to launch the handler via the file:

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

The specific cron line depends on the environment. It is important to check not only the existence of the task, but also the actual execution:

• path to the CLI version of PHP and the site root;
• the user under which PHP is running;
• coincidence of critical settings of the CLI and the web environment;
• exit code and stderr of the cron command;
• rights to cache, logs and temporary directories;
• SMTP availability from the same user;
• reduction in the number of events N after launch.

The documentation specifically warns: the cron user must match the web server user, otherwise there may be problems with rights and different environment settings.

After fixing, run one test event, check its path from N until the sending result and only then return processing of the entire queue.

Queue or immediate dispatch: what to choose

For most business notifications, a queue is preferable: the user does not wait for an SMTP response, and temporary unavailability of the mail server does not break the ordering process or form submission.

Immediate dispatch is only useful where the team consciously accepts the delay of the external service:

use Bitrix\Main\Mail\Event;

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

Don't translate all events to sendImmediate for the sake of bypassing faulty cron. This masks the problem and moves the dependency on SMTP to the user request.

How to prevent b_event from overflowing again

Add four indicators to your monitoring:

• number of events N older than the allowed time;
• age of oldest event N;
• number F and 0 for the last hour;
• speed of appearance and processing of new records.

Set up a notification before the queue is visible to users. It is also useful for an online store to separate critical transactional emails and marketing mailings, limit repeated event calls, and store the correlation ID of the order or application in the application logs.

If diagnostics show system problems with cron, SMTP, kernel updates or custom handlers, you need not just another SQL query, but audit and project support on 1C-Bitrix.

FAQ

Is it possible to remove all entries from b_event

Technically possible, but for a production site there is a risk of losing current notifications and diagnostic data. It is safer to back up and delete only verified entries by ID, event type, status and date.

Why are there many entries in b_event with status N

Status N means that the sending result has not yet been recorded. If old entries do not change for a long time, check background jobs, cron and startup cron_events.php. If new entries are being processed but appearing faster than they disappear, look for duplicate code or insufficient submit bandwidth.

What is the difference between SUCCESS_EXEC N and F

N usually means waiting for processing, and F — unsuccessful attempt to send. For F see SMTP/MTA logs and settings sendmail_path; for long term N — a mechanism for launching mail events.

What does SUCCESS_EXEC equal to 0 mean?

This is usually the lack of a suitable active email template. Check the event type, template binding to the site, language and transmitted MESSAGE_ID.

Why didn't the letter arrive, although SUCCESS_EXEC is equal to Y

Y does not confirm delivery to the mailbox. The email could have been accepted by the local MTA or SMTP gateway and then rejected, bounced, or placed in spam. Check email service logs, SPF, DKIM, DMARC and sender reputation.

Do I need to move mail events to cron?

For a commercial project, cron gives a predictable start regardless of traffic. The setup must be performed according to the documentation for your version of 1C-Bitrix and be sure to check user rights, PHP CLI configuration and execution logs.

Useful on the topic

• Development and support of websites on 1C-Bitrix
• How to programmatically delete an order in 1C-Bitrix on D7
• 1C-Bitrix or WordPress: comparison of platforms
• Case: transfer of a corporate website of RKS to 1C-Bitrix

Sources

• 1C-Bitrix: mail system device and SUCCESS_EXEC values
• 1C-Bitrix: CEvent::Send
• 1C-Bitrix: CEvent::CheckEvents
• 1C-Bitrix: CEvent::SendImmediate and result codes
• 1C-Bitrix D7: Bitrix Main Mail Event::send
• 1C-Bitrix: launching agents from cron