Cron Configuration for Automatic Tasks in 1C-Bitrix
Without a properly configured cron, agents stop working in Bitrix: emails aren't sent, prices from 1C aren't updated, expired carts aren't deleted. The standard "agents via page hits" mechanism (where an agent runs on every user request) creates unpredictable delays and slows down page responses during heavy tasks.
Two Agent Execution Modes
Bitrix supports two modes — via page hits and via cron. Switching: Settings → Product Settings → Agents.
Hit mode (default): agents run on normal site requests. The downside — execution delay depends on traffic. At night, when indexing or sending a newsletter needs to run, there may be no hits at all.
Cron mode: agents are executed by the system scheduler independently of traffic. This is the only correct option for production.
System Cron Configuration
After switching the mode, add a task to the crontab of the web server user (usually www-data or bitrix):
*/5 * * * * /usr/bin/php -f /var/www/html/bitrix/modules/main/tools/cron_events.php >> /var/log/bitrix_cron.log 2>&1
The execution interval — from 1 to 5 minutes. More frequent is unnecessary: most agents have a minimum period of 1 minute, and more frequent runs achieve nothing.
The PHP path must match the one used by the web server. Check with: which php or php -v. If there are multiple PHP versions on the server — specify the full path, e.g. /usr/bin/php8.1.
Separate Cron for Composite Cache and Search
If the Search or Web Analytics module is in use, add separate tasks:
0 3 * * * /usr/bin/php -f /var/www/html/bitrix/modules/search/lib/crawler.php
0 2 * * * /usr/bin/php -f /var/www/html/bitrix/modules/statistic/tools/update_daily_counter.php
For sites on "Bitrix: Site Management" with the sale module — run order processing separately:
*/10 * * * * /usr/bin/php -f /var/www/html/bitrix/modules/sale/lib/internals/agent.php
Real-World Case
An online store on the "Small Business" edition, hosted on a virtual server. Complaint: payment confirmation emails are delayed by 2–4 hours, sometimes not sent at all. Diagnosis: agents were running in hit mode, with no traffic at night. The mail queue in b_event was accumulating, and the main module wasn't running. Solution: switched to cron with a 2-minute interval and added a mail queue processing task. After the change — emails are sent within 2 minutes of the triggering event.
Monitoring Execution
To check when agents last ran: the b_agent table in the database, the LAST_EXEC field. If the value isn't updating — cron isn't working.
In the admin interface: Settings → Performance → Agents. Shows the last run time and a list of agents with their schedules.
Execution Timelines
Cron setup for a typical server — 1–2 hours, including verifying that all agents are working and configuring logging.