We often see: a Bitrix site with manual price and stock updates — errors, delays, lost sales. A client once came to us with a catalog of 15,000 items: prices were updated once a week manually via Excel. In a month, losses from expired promotions amounted to 8% of turnover. One-time parsing doesn't solve it — you need automatic scheduled execution. Setting up a parser on a schedule (cron) for 1C-Bitrix is a key task for automating data updates. We select the mechanism (Bitrix agents vs system cron), implement parallel run locking, set up logging and alerts. The result: data updates automatically, without human intervention.
How does system cron solve the data update problem?
Agents (b_agent) are Bitrix's built-in mechanism. They only fire when a visitor hits the site and CAgent::CheckAgents() runs. With low traffic, agents run late. The exact launch mode via cron solves the issue but requires system cron configuration. Our experience shows: for parsers that update every 30 minutes, system cron is more reliable.
System cron directly calls PHP-CLI. No dependency on the web server:
*/30 * * * * /usr/bin/php -f /var/www/site/local/scripts/parser_run.php >> /var/log/parser.log 2>&1 For heavy parsers (10,000+ items), system cron is preferable — no PHP-FPM execution time limits. We guarantee stable execution at any time, even when the site is idle.
Why we recommend system cron for heavy parsers?
On a project with 50,000 products updated every 30 minutes, agents struggled: with 200 visitors per day, execution slipped by 10-15 minutes. Switching to system cron eliminated the delays — updates became precise to the second. Support costs dropped by 30% due to automation.
How to protect the parser from parallel runs?
The parser runs for 25 minutes, cron triggers the next after 30 — two instances won't overlap. But what if the script hangs for 35 minutes? You need protection. We use file-based locking or Redis:
$lockFile = '/tmp/parser_' . md5($parserName) . '.lock'; if (file_exists($lockFile) && (time() - filemtime($lockFile)) < 3600) { exit('Already running'); } touch($lockFile); // ... parser work ... unlink($lockFile); For distributed systems (multiple servers) — Redis locking: SET lock:parser NX EX 3600. The cost of a parallel run error: duplicate data and server load. We account for this in every project.
Agents or cron: which to choose? Comparison
| Criterion | Bitrix agents (b_agent) |
System cron |
|---|---|---|
| Dependency on traffic | Yes | No |
| Execution time limit | Limited by PHP-FPM (usually 300 s) | No limit (PHP-CLI) |
| Launch precision | ± few minutes at low load | ± second |
| Setup complexity | Built-in, no server access needed | Requires SSH and permissions |
| Suitable for heavy parsers | Conditionally | Yes |
| Logging support | Via agent methods | Configured separately |
Step-by-step cron setup for a parser
- Determine the launch command — full path to PHP and script. Check version:
which php. - Set up logging — redirect stdout and stderr to a dated log file.
- Add the job to crontab —
crontab -e, specify schedule and command. - Implement locking — lock file or Redis.
- Test — run the command manually, check logs.
- Set up alerts — send notifications on errors.
We apply this algorithm in every project — it reduces debugging time by 40%.
Setting up Bitrix agents for parsing
If agents are still used — register via CAgent::AddAgent():
CAgent::AddAgent( 'MyParserAgent::Run();', // agent function 'mymodule', // module 'N', // not exact 3600, // interval in seconds '', // first launch date 'Y', // active date('d.m.Y H:i:s', time() + 3600) // next launch ); The agent must be registered in the module's include.php or in init.php. For production, we recommend combining with system cron via 1C-Bitrix documentation. This gives maximum flexibility and precision.
What does structured logging provide?
A parser without logs is a black box. Minimum scheme:
file_put_contents($logFile, date('[Y-m-d H:i:s] ') . $message . PHP_EOL, FILE_APPEND); For production — structured logs with levels (info/warning/error) and rotation via logrotate. Alert on error: if the last run's log contains ERROR lines — send an email via \Bitrix\Main\Mail\Event. This cuts response time to failures and halves support costs. According to Bitrix recommendations, such monitoring is mandatory for critical updates.
What's included in the work
- Audit of the current parser or writing a new one
- Selection and setup of the launch mechanism (cron/agents)
- Implementation of parallel run locking
- Configuration of logging and alerts
- Schedule testing and error scenario testing
- Documentation on access and parser operation
- One-week stability guarantee after launch
Timeline
| Stage | Duration |
|---|---|
| Setting up system cron or Bitrix agent | 1–2 hours |
| Implementing parallel run locking | 1–2 hours |
| Setting up logging and alerts | 2–4 hours |
| Schedule testing | 2–4 hours |
Total: 6–12 hours. Cost is calculated individually — we'll evaluate your project within one business day.
Get a consultation on parser setup — write to us, we'll find the best solution for your budget. Leave a request — we'll tell you how to automate data updates on your project. Contact us to start automation today.