Without correctly configured cron in Bitrix, agents stop working: emails don't send, prices from 1C don't update, expired carts are not deleted. On Bitrix projects, a typical problem is the 'via hits' agent mode (launch on each user request). This creates unpredictable delays: resource-intensive agent operations (price recalculation, sending newsletters) only execute when there is traffic, and the site experiences zero traffic at night, leaving agents unexecuted. We have encountered projects where payment emails were delayed up to 4 hours (80% of orders affected), and the mail queue in b_event accumulated up to 5000 messages. This led to reduced conversion — customers did not receive order status notifications. The only correct solution is to switch agents to system cron. In this article, we will look at how to set up cron for production, avoid common mistakes, and reduce delays to 1-2 minutes.
Agent launch modes: hits vs cron
Bitrix supports two modes — via hits and via cron. Switch: Settings → Product Settings → Agents.
Hits mode (default): agents run on regular site requests. Downside — execution delay depends on traffic. At night, when you need to run indexing or send a newsletter, there may be no hits at all. As a result, agents accumulate and pages slow down.
Cron mode: agents run via the system scheduler daemon independently of traffic. This is the only correct option for production: agents execute strictly on schedule without affecting user experience.
Which mode is more reliable?
| Characteristic | Hits mode | Cron mode |
|---|---|---|
| Traffic dependency | Full | None |
| Execution accuracy | Low (up to several hours delay) | High (within launch interval) |
| Server load | Bursty on mass launches | Even |
| Risk of missing agents | High when no hits | Minimal |
| Recommendation | Only for development | For production |
Cron mode is 10 times better than hits mode in agent execution accuracy. Saving time on manual agent launch saves the administration budget.
Cron setup: step-by-step guide
- Switch the agent mode in the admin panel to 'cron'.
- Determine the web server user (usually www-data or bitrix).
- Add a task to this user's crontab:
*/5 * * * * /usr/bin/php -f /var/www/html/bitrix/modules/main/tools/cron_events.php >> /var/log/bitrix_cron.log 2>&1 Launch interval — from 1 to 5 minutes. More often is unnecessary: most agents have a minimum period of 1 minute, and more frequent launches won't help.
The path to PHP must match the one used by the web server. Check: which php or php -v. If there are multiple PHP versions on the server, use the full path, e.g., /usr/bin/php8.1.
- Ensure the log file is created and not empty:
tail -f /var/log/bitrix_cron.log.
Additional cron tasks
If you use the Search or Web Analytics module, 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 Manager with the sale module — launch order processing separately:
*/10 * * * * /usr/bin/php -f /var/www/html/bitrix/modules/sale/lib/internals/agent.php If you use phpmailer, the mail queue requires cron for timely delivery. For sites with 1C integration, set up a dedicated cron for 1C exchange to avoid delays in data synchronization.
Example of typical tasks:
| Task | Command | Periodicity |
|---|---|---|
| Main agents | cron_events.php | 2–5 minutes |
| Search crawler | crawler.php | Once daily |
| Order processing | sale/lib/internals/agent.php | 10 minutes |
| Sending email notifications | Via main agent | 1–2 minutes |
Why is cron important for an online store?
Online stores depend on timely order processing, stock updates, and sending notifications. If agents execute with delay, customers don't receive payment emails, and managers don't get new order alerts. We encountered a project where due to hits mode, emails were delayed by 4 hours. After setting up cron, the delay dropped to 1–2 minutes.
Case study
One of our clients, an online store on the Small Business edition, hosted on a virtual server. Complaint: payment emails arrive 2–4 hours late, sometimes not at all. Diagnosis: agents were running in hits mode, no traffic at night. The mail queue in b_event accumulated, the main module wouldn't start. Solution: switched to cron with a 2-minute interval, added a mail queue processing task. After the change, emails are sent within 2 minutes of the event.
How to check if cron is working?
Check when agents last executed: in the b_agent database table, the LAST_EXEC field. If the value isn't updating, cron isn't working.
In the administrative interface: Settings → Performance → Agents. You can see the last launch time and a list of agents with their schedules.
Also refer to the official Bitrix documentation for agent setup to verify parameters. Read more about cron on Wikipedia.
Common mistakes when setting up cron
- Incorrect PHP path (especially on servers with multiple versions).
- Forgot to switch agent mode in the admin panel.
- Didn't create a log file or insufficient write permissions.
- Agents locked in b_agent (IS_LOCK = Y) after a crash — need manual clearing.
What's included in the setup work
- Analysis of current configuration: checking agent mode, agent composition, presence of locks.
- Crontab configuration: adding tasks with correct PHP paths, logging.
- Testing all agents: ensuring each agent runs on time.
- Periodicity optimization: adjusting intervals for load.
- Documentation: description of all added tasks, restart schemes.
- Consultation: answering questions, training on cron usage.
Timelines and cost
With over 7 years of Bitrix expertise and 60+ successful cron migrations, we ensure reliable agent execution. Setting up cron for a typical server takes 1–2 hours, costing between $100 and $200. For complex projects, up to $400. Cost is calculated individually, depending on complexity. Contact us for an accurate estimate of your project — we'll find the optimal solution.
Order professional cron setup for Bitrix with a guaranteed result. Get a consultation — we'll assess your project, prepare the configuration, and conduct testing.