Setting up a scheduled parser (cron) for 1C-Bitrix

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

Configuring a Scheduled Parser (cron) for 1C-Bitrix

A one-off parser is a one-off solution. Real value begins when the parser runs automatically on a schedule: updating prices, stock levels, and descriptions without human intervention. In 1C-Bitrix this can be organized through the built-in agents, the system cron, or queues — each approach has its own limitations.

1C-Bitrix agents vs system cron

Agents (b_agent) — the built-in mechanism. They run on web requests to the site: an agent executes when someone opens a page and the CAgent::CheckAgents() check triggers. The problem: on low-traffic sites, agents do not run on time. Agent reliability improves by enabling "Exact agent execution" mode via cron — agents then run from a system job rather than from a visitor's browser.

System cron — more reliable for parsers. A direct PHP-CLI call with no dependency on traffic:

*/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.

Protection against parallel execution

The parser runs for 25 minutes, cron triggers the next one in 30 — two instances won't overlap. But what if the parser hangs and runs for 35 minutes? Protection:

$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) — lock via Redis: SET lock:parser NX EX 3600.

Configuring 1C-Bitrix agents for parsing

If agents are used, register them via CAgent::AddAgent():

CAgent::AddAgent(
    'MyParserAgent::Run();',  // agent function
    'mymodule',               // module
    'N',                      // not exact
    3600,                     // interval in seconds
    '',                       // first run date
    'Y',                      // active
    date('d.m.Y H:i:s', time() + 3600)  // next run
);

The agent must be registered in the module's include.php or in init.php.

Logging and monitoring

A parser without logs is a black box. Minimal logging 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 log for the last run contains any lines with ERROR — send an email via \Bitrix\Main\Mail\Event.

Work timeline

Phase Duration
Setting up system cron or 1C-Bitrix agent 1–2 hours
Implementing parallel execution lock 1–2 hours
Setting up logging and alerts 2–4 hours
Testing the schedule 2–4 hours

Total: 6–12 hours — a straightforward task, but critical for the reliability of the entire parsing system.