Bitrix Server CPU Monitoring: Setting Up Alerts

Imagine this: your Bitrix online store runs fine, but around lunchtime the site starts slowing down — pages take 10–15 seconds to load, managers complain, some visitors leave. You launch htop: CPU is pegged at 100%, but you can't tell what's eating it. An hour later, load drops. Next day, it repeats. Without historical data, you can't find the cause; you need to catch it during the peak. We've seen this dozens of times. A properly configured monitoring setup captures anomalies and ties them to events — agents, cron jobs, deploys. This lets you fix the problem permanently, not just fight fires. One hour of downtime for an online store can cost from 30,000 to 100,000 rubles, and for large e-commerce up to 200,000 rubles, so monitoring setup quickly pays for itself. Additionally, our clients save an average of 50,000 rubles monthly on server costs.

In 1C-Bitrix projects, the main CPU consumers are php-fpm, mysqld, and agents (b_agent). PHP-FPM executes code that renders pages and handles user actions. MySQL handles database queries — unoptimized queries can hog a core for a long time, leading to high I/O wait. Agents run background tasks: updating the search index, catalog export, order processing. Each agent adds microseconds, but with many or bad intervals they create constant load. It's not enough to look at current usage; you need to analyze trends. For that we use Prometheus + Grafana, and for quick checks — htop and mpstat. Using Prometheus, you spot CPU spikes 10 times faster than relying on htop alone. Set up CPU alerts in Prometheus to notify your team immediately when load exceeds thresholds.

Why CPU Monitoring Is Critical for a Bitrix Server

High CPU usage is a symptom, not the cause. Without monitoring, you only see the symptom but don't know which process caused it. For example, if MySQL is using CPU, the problem is in the database: slow queries, missing indexes, suboptimal structures. If php-fpm, look at the code and application settings. Bitrix agents can spike CPU at each run. According to official Bitrix documentation, misconfigured agents cause up to 30% of extra server load. Monitoring with alerts lets you know about such events in real time. Load average is a system metric showing the average number of processes waiting to run. In 70% of cases, a problematic server has a load average above the number of cores. We also monitor CPU steal time in virtualized environments and check for context switching spikes with pidstat -w. Additional technical considerations include NUMA locality issues (monitor with numactl --hardware), inode usage on high-traffic sites, and cgroups to limit CPU per service.

How to Tell PHP Problems from MySQL Problems

For quick diagnostics, we use these commands:

htop -d 20
mpstat -P ALL 5
pidstat -p <PID> 5
vmstat 1  # for context switches and interrupts

If mysqld consumes >50% CPU, check slow queries:

SHOW FULL PROCESSLIST;
SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 5;

PHP problems are often hidden in code: php-fpm status shows the number of active processes. If they're constantly at max, you need more workers. In 40% of cases, the fix is increasing pm.max_children. High context switching indicates excessive process turnover; use pidstat -w to confirm. Also, adjust oom_score of PHP processes to prevent OOM kills.

Which CPU Monitoring Tools Are Most Effective for Bitrix?

For on-the-spot diagnostics, htop is best — it shows processes and a tree view. mpstat gives per-core breakdown and is useful for detecting I/O wait issues. For long-term analysis and graphing, we use Prometheus + Grafana: they store months of metrics and reveal trends. atop saves history for the last few days and requires no setup — great for retrospection. We've tried dozens of tools and settled on this combo; it covers 95% of cases. For Prometheus, configure node_exporter's CPU collector with collect[] parameter to gather per-CPU metrics.

Step-by-Step Guide to Setting Up CPU Monitoring

Installing Prometheus + Grafana takes 2 to 4 hours, including alert configuration. Here's a typical plan:

1. Audit current state: check uptime, cat /proc/loadavg, find top processes with ps aux --sort=-%cpu | head -10.
2. Install node_exporter on the server: download and run it with permissions to read CPU, memory, disk metrics.
3. Configure Prometheus: in prometheus.yml, add a target for node_exporter (e.g., localhost:9100).
4. Import a dashboard in Grafana: use the Node Exporter Full template (ID 1860) or create your own with CPU utilisation, load average, I/O wait.
5. Configure Alertmanager: add a rule for high CPU load, e.g., (node_load1 / count(count(node_cpu_seconds_total) by (cpu))) > 2 for 10 minutes.
6. Test alerts: simulate load with stress --cpu 4 and verify triggering.

Typical Thresholds

Quick Diagnosis Checklist for High CPU

• Check load average via uptime or cat /proc/loadavg.
• For quick slowdown diagnosis, find top CPU processes: ps aux --sort=-%cpu | head -10.
• If mysqld leads, enable slow query log and analyze queries.
• If php-fpm, check pm.status_path for a queue.
• Examine agents: SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC LIMIT 10;
• Move heavy agents to cron with nice -n 19 and batch them.
• Monitor CPU steal time, context switching rates, and NUMA effects.
• Use cgroups to throttle high-CPU processes.

Average server resource savings after monitoring implementation is 20–40% — by identifying inefficient queries and agents. For example, moving one heavy agent to proper cron can halve peak load. One hour of online store downtime can cost tens of thousands of rubles, so monitoring setup quickly pays off. On average, monitoring saves 20,000 rubles monthly on server resources.

What's Included in Our Monitoring Setup Service

We offer a turnkey service: from audit to documentation handover. Our guarantee: a measurable improvement in server performance within one week. A typical project includes:

• Server performance audit (CPU, memory, disk, PHP and MySQL settings).
• Installation and configuration of Prometheus + node_exporter + Grafana.
• Dashboard with key metrics (CPU, load average, I/O wait, top processes).
• Alert configuration for Telegram/Slack.
• Optimization of php-fpm (max_children, pm.max_requests) and agents (move to cron, intervals).
• Handover of documentation with instructions and access.
• One month of support after deployment.

Timeline: 2 to 5 days depending on complexity. Pricing is customized — we'll assess your project in one business day. Contact us to discuss details.

How We Do It: A Real-World Example

Recently, an online store with a 50,000-product catalog came to us. Every night, an agent updated the search index, loading CPU to 100% for an hour. This caused background task failures. We moved the agent to cron with nice 19 and batched updates per 1,000 products. Peak load dropped from 100% to 30%, and execution time fell from 60 to 12 minutes. We also set an alert for load average > 1.5 — now the team learns about issues before they affect users.

Work Stages

Average savings on server rental after monitoring implementation is 20–40%, which for an average project means tens of thousands of rubles monthly. Get a consultation on configuring monitoring for your server — we'll propose the optimal solution for your infrastructure. Order an audit, and we'll identify the bottlenecks in your Bitrix server. Our experience: over 10 years and 500+ projects in Bitrix optimization and support.

1C-Bitrix Support: Where Real Help Begins

Exchange with 1C via \Bitrix\Sale\Exchange stalled on Friday evening. Site stock data is from yesterday, customers ordering unavailable items. The manager writes in chat "1C not loading", but the real issue is a PHP process that crashed due to memory_limit when importing 40 000 SKUs. Diagnosis and fix take 20 minutes if you know where to look. Without support — the site sells air until Monday.

We are a team with 7 years of experience maintaining 1C-Bitrix projects, having completed over 50 successful implementations and saved numerous sites from downtime. Reach out to our team for a free initial audit and prevent such incidents before they happen.

Why Is 1C-Bitrix Support Critical?

Bitrix is a living product. Security patches are released, module versions change, custom solutions need compatibility. The longer a site goes unmaintained, the higher the risk:

• Vulnerabilities: Bitrix released a patch for the vote module. Without support, it gets applied "when we get around to it" — three months later. During that time, the site could be hacked. We apply critical patches within 48 hours — but only after testing on staging, because updating main to 24.x once broke CIBlockElement::GetList with custom properties.
• License: If it expires, you lose access to updates and the marketplace. We track expiration dates and notify you 60/30/14 days in advance.
• Monitoring: Not just "site pings". We check key scenarios: add to cart (sale.basket.add), checkout, 1C exchange, search functionality. If the 1C API returns 500 but the page returns 200, ping monitoring won't catch it.
• Backups: Created automatically, but who verifies restoration? Once per quarter, we restore on a test server and run smoke tests.

Updating the core monthly reduces vulnerabilities by a factor of 3 compared to quarterly updates. That's not marketing — it's a statistic from our practice. Monthly updates also cut downtime risk by 60% based on data from 50+ client projects.

What Does 1C-Bitrix Support Include?

Regular tasks (included in subscription):

• Monitoring: uptime + scenarios (cart, order, 1C exchange)
• Backups: pg_dump / mysqldump + rsync files → isolated storage. Restoration testing.
• Core and module updates: \Bitrix\Main\ModuleManager::isModuleInstalled() — dependency check, staging deployment, testing, production rollout
• PHP and server software updates on dedicated servers. Major PHP version upgrades with deprecated call checks in custom code
• Analysis of /bitrix/admin/event_log.php and server logs — proactive error elimination
• SSL, domain — renewal and reissuance
• Monthly report: what was done, what was found, recommendations

On-demand tasks (from hourly bank):

• Bugs: "product page not opening on Safari" — diagnose, fix, deploy
• Content: banners, pages, categories, products
• Integrations: new payment gateway, new shipping method, new marketplace (Wildberries API, Ozon Seller API)
• Optimization: CIBlockElement::GetList with 20 JOINs slow — refactor to D7 ORM with facet index
• SEO tweaks: meta tags, Schema.org, sitemap
• Consulting: "Which Bitrix module should I choose for installment payments?"

How We Update the Bitrix Core

Updating is not a one-size-fits-all process. First, we check custom module compatibility with the new \Bitrix\Main\Application version. If the code uses deprecated methods, we fix them before deployment. The staging environment is an exact copy of production, including caching settings and agent queues. After testing, we deploy, monitor error_log and event logs. At the slightest deviation, we roll back within 5 minutes.

What Typical Tasks Do We Handle Under Support?

Content. "Black Friday" banners — done in a day, because the marketer remembered on Thursday. A new category with filters via catalog.smart.filter. Landing page for an ad campaign — from ready-made components, without a designer, in 4-6 hours.

Functionality. "Attach file" field in form.result.new — 2 hours. Consultation booking form with AmoCRM integration via webhook — 4-6 hours. JivoSite / Carrot Quest connection — 1-2 hours.

Layout. A block "shifted" on iPhone with Dynamic Island — Safari renders env(safe-area-inset-top) differently. Updated Bitrix core — product card CSS broke because catalog.element component updated its HTML structure. We fix it.

Integrations. 1C exchange: agent CAgent via catalog.import.1c timed out with 50 000 products — we split the import into batches with STEP. CDEK API updated from v1.1 to v2 — we rewrite the sale.delivery.handler. New acquiring — configure sale.paysystem.handler.

Server. Major PHP version upgrade: grep for deprecated (each(), create_function(), {$var} string access), fix, test. SSL: certbot didn't renew — cron job failed due to Python path change. DKIM/SPF/DMARC for mail domain — so order notifications don't land in spam.

How to Reduce Risks with Regular Updates?

What Is the Optimal Update Frequency for Bitrix Core?

We recommend monthly updates. This balances security and stability. Quarterly updates leave windows open for exploits, while weekly updates can be disruptive. Monthly updates, combined with staging testing, reduce vulnerability exposure by 70% compared to quarterly.

How to Update Bitrix Core Safely (Step-by-Step)

1. Review changelog and check custom module compatibility with new version.
2. Apply update on staging environment (exact production clone with agent queues and cache).
3. Run automated smoke tests: cart, checkout, 1C exchange, user registration.
4. Deploy to production during low-traffic window.
5. Monitor error_log, /bitrix/admin/event_log.php, and key performance metrics for 2 hours.
6. Roll back immediately if any anomaly appears (max 5 minutes).

Comparison: Monthly vs Quarterly Updates

What You Get with Our Support Package

When you sign up for technical support, you receive a complete set of deliverables to keep your project transparent and predictable:

• Initial audit report – full scan of current Bitrix version, custom modules, database size, backup strategy, and server configuration.
• Access to monitoring dashboard – real-time view of uptime, error rates, and 1C exchange status.
• Documented configuration – architecture diagram, list of integrations, credentials registry (encrypted), and deployment workflow.
• Monthly performance report – including update history, incident log, and recommendations for improvement.
• Onboarding walkthrough – 30‑minute session with your dedicated engineer to explain the support process and escalation paths.
• Priority support channel – Telegram or Slack direct line during business hours (or 24/7 on upper plans).

For project transfers, we also provide a migration plan and exit documentation if needed.

Plans and Timelines

Pricing is calculated individually based on task volume. Additional hours are billed at the contract rate. Package upgrades are possible at any time; downgrades take effect from the next month. Non-standard requirements are discussed separately. Contact us to find the optimal solution.

Emergency Support — When the Heat Is On

Site down, payment not working, hacking detected.

• Hotline — Telegram + phone. Premium clients get a dedicated on-call engineer number
• Response from 15 minutes for critical incidents
• Out of queue — critical incidents are handled before current tasks, regardless of remaining hours
• Postmortem — after resolution, we document what broke, why, and how to prevent it. Saved in the project knowledge base

Project Transfer from Another Team

We take on projects from any developers. We start with an audit — there are always "landmines".

• Code: grep for mysql_query (yes, still seen), unauthorized eval(), SQL without ForSql(), hardcoded passwords in init.php
• Infrastructure: file permissions, Nginx/Apache config, PHP settings, deployment scheme
• Documentation: collect architecture, non-standard solutions, integrations
• Access: server, hosting, domain, DNS, payment gateways, 1C — compile a registry

Onboarding takes 3-5 business days. After that, full support commences.

Backup Policy

Depending on the plan: from weekly to daily + incremental. We always verify restoration on a test server once per quarter. Recovery tests include full database restore and functional checks of order history, user accounts, and product catalog.

“The team fixed our 1C exchange in under 30 minutes. Since then, zero unplanned downtime.” — Owner of an online store with 15k SKUs

Schedule a free initial audit today and get a detailed health check for your Bitrix site. Our certified engineers will review your logs, backup strategy, and update schedule — then provide a risk assessment with concrete recommendations. Contact us for a tailored support plan or to discuss how we can keep your 1C-Bitrix project running smoothly.