Cron setup for automatic tasks in 1C-Bitrix

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?

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

1. Switch the agent mode in the admin panel to 'cron'.
2. Determine the web server user (usually www-data or bitrix).
3. 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.

4. 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:

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.

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.

Problems We Solve

rsync -avz to production on Friday evening, restart php-fpm, and the site returns 502 — local database settings remain in .settings.php. Classic “deployment the old way” turns into a lottery. Another scenario: a module update from the admin panel breaks a custom component template — changes aren’t tracked in version control, recovery takes hours. Without a DevOps culture, every release is a gamble.

We design a predictable DevOps cycle for 1C-Bitrix: from Docker environment to Telegram alerts. Each deployment becomes routine, each incident triggers a context‑rich alert. Below is how we solve real Bitrix team problems — with numbers, tools, and proven configurations.

Why DevOps Is Critical for Bitrix Projects?

Bitrix projects carry specific infrastructure requirements: heavy e‑commerce catalogs, 1C exchange via CommerceML, dozens of agents and events. Without CI/CD and monitoring, every change introduces risk. A single stuck agent can silently break a 1C sync for hours; a manual deployment mistake can cost a client lost orders. We’ve seen teams spend 12 hours per month just on manual deployments and crash recovery — after our CI/CD pipeline, that drops to zero.

CI/CD Pipeline: From Commit to Production Without Hands

Git migration – we move the project from FTP to Git (GitLab, GitHub, Bitbucket). Branch structure: main (production), staging, develop, feature branches. A proper .gitignore for Bitrix is non‑trivial:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Miss managed_cache/ → the repository bloats to gigabytes. Forget license_key.php → the key leaks.

CI pipeline – automatically runs PHPStan level 5+, PHP_CodeSniffer with Bitrix standard, PHPUnit for business logic, composer audit, frontend build.

CD pipeline – deploys without human intervention. Merge to staging → deploy to staging. Merge to main → deploy to production (with optional manual confirmation). Zero‑downtime via symlink strategy: new version in a separate folder, current → symlink switches in milliseconds. upload/ lives outside release directories. Healthcheck fails → symlink rolls back automatically. Tools: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer’s built‑in recipes for Bitrix handle shared directories and symlink deployment out‑of‑the‑box.

Docker Environment: How We Eliminate “It Works on My Machine”

The Docker environment fixes versions of all components: nginx, PHP, MySQL, Redis. Configuration mirrors production — same PHP modules, same php.ini.

Local development – docker-compose.yml includes nginx + php‑fpm 8.1/8.2 + MySQL 8.0 (or MariaDB 10.6) + Redis + Memcached. New developer: git clone + docker-compose up -d → writes code within 5 minutes. Parallel work on different PHP versions via separate compose files.

Bitrix specifics in Docker:

• /upload/ mounted as a named volume (not bind mount — permission and speed issues on Windows/Mac).
• Cron jobs (/bitrix/modules/main/tools/cron_events.php) run via a separate container with supervisord.
• “Proactive Protection” module (security) blocks requests through reverse proxy — need set_real_ip_from and realip_module.
• Database config (dbconn.php, .settings.php) set via environment variables, never through a volume with production configs.

Production – multi‑stage Dockerfile (build stage for assets, production stage with lightweight image), Docker Registry for tagged images, orchestration via Docker Swarm or Kubernetes for large projects.

Nginx and PHP‑FPM Configuration for Bitrix Performance

The difference between “site is slow” and 200 ms TTFB lies in configuration. nginx:

• location blocks for Bitrix handle urlrewrite.php for friendly URLs.
• /bitrix/admin/ IP‑restricted via allow/deny.
• expires 30d for static files — CSS, JS, images cached by the browser.
• Brotli compression (15‑20% better than gzip): brotli on; brotli_comp_level 6;.
• Rate limiting on /bitrix/tools/ protects against brute force.
• HTTP/2 push for critical resources.

php‑fpm: pm = dynamic. Calculate pm.max_children: (RAM - RAM_other_services) / avg_memory_per_process. For Bitrix, avg is 40–80 MB. OPcache: opcache.memory_consumption=256 (default 128 is insufficient — Bitrix loads thousands of files), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 in production (reset via cachetool opcache:reset on deployment). php.ini: memory_limit=256M (up to 512M for heavy imports), max_execution_time=60, upload_max_filesize=100M. Slowlog with request_slowlog_timeout=5s catches bottlenecks before users complain.

Monitoring and Logging: What We Track

Infrastructure – Prometheus + Grafana: metrics for CPU, RAM, disk, network, service status. Alerts: CPU > 80% for 5 minutes, free RAM < 500 MB, disk > 85%, php‑fpm queue > 0 (worker shortage). Node Exporter, MySQL Exporter, PHP‑FPM Exporter collect data.

Application – Uptime check every 60 seconds → Telegram alert within a minute of downtime. Response time of key URLs: /, /catalog/, /personal/order/make/. Sentry for PHP errors — structured errors with context. Bitrix agents (b_agent): we check NEXT_EXEC < NOW() - INTERVAL 1 HOUR — a stuck agent silently breaks 1C exchange.

Logging – ELK Stack or Loki + Grafana: nginx access/error, php‑fpm slow log, MySQL slow query log, Bitrix errors. Rotation via logrotate — without it, access.log takes 50 GB after six months.

Backup Strategy and Disaster Recovery

Geographic distribution — S3‑compatible storage + separate server in another datacenter. Test restoration monthly — a backup never restored is just an illusion of security. Cron with notifications: if backup fails, alert immediately.

What’s Included in the Service

Our team brings 5+ years of Bitrix DevOps experience (over 50 successful projects) and certified engineers. The service provides:

• DevOps process documentation (deployment scheme, branch policy, infrastructure description)
• Configured CI/CD pipelines (GitLab CI / GitHub Actions) with working triggers
• Docker environment (docker-compose.yml, Dockerfile, configs)
• Ansible playbooks for server reproduction
• Monitoring (Grafana dashboards, alerts in Telegram / Slack)
• Secured access with role‑based model
• Team training: two sessions on CI/CD, Docker, and deployment
• Support during implementation (two weeks after launch)

Infrastructure‑as‑code with Ansible is 5× faster than manual server configuration and eliminates human errors.

Implementation Process and Timelines

1. Audit of current state – assess infrastructure, software, processes (2–3 days).
2. Architecture design – choose stack (Docker / K8s / Ansible), agree on CI/CD policies, set up repository.
3. Environment setup – Docker for local development, staging, production servers.
4. CI/CD implementation – write pipelines, test deployment, integrate with monitoring.
5. Monitoring and alerting – install Prometheus + Grafana, configure dashboards and notifications.
6. Team training – two sessions on tool usage.

DevOps is not a project with an end date — it’s a transition from “upload via FTP and pray” to predictable processes. Each deployment is routine, each incident carries context, each new developer does docker-compose up instead of a three‑day environment setup.

Get a consultation – we’ll prepare a tailored implementation plan within 2–3 days. Order a turnkey DevOps implementation – gain stability and full control over your infrastructure.