Your site went down at three in the morning. When the manager opens the browser in the morning — white screen of death (WSOD). They call us. We connect and find a disk I/O bottleneck or a MySQL server crash due to buffer pool overflow. Clients saw error 500 all night. The damage: lost orders, reputation, search rankings. We provide 1C-Bitrix performance monitoring and proactive downtime prevention: you learn about the failure before your customers do. With over 10 years of Bitrix administration and 500+ projects completed, we guarantee SLA up to 99.9%. For a store with $200k monthly revenue, each hour of downtime costs approximately $6,900, making our setup a no-brainer.
Which metrics to monitor?
Site availability is not a single metric but a set of indicators. Each catches a specific type of failure.
HTTP status of the homepage and key pages. An external checker (UptimeRobot, Hetrixtools, Zabbix with an external node) sends a GET request every 60 seconds and checks the response code. 200 is normal, 500/502/503 triggers an alert. It's important to check not only the homepage but also the product catalog page, cart, and personal account — they use different modules and may fail independently.
Response time (TTFB). The site responds, but takes 8 seconds — that's still a failure. Threshold: TTFB > 2 seconds is a warning, > 5 seconds is a critical alert. An increase in TTFB often precedes a complete crash: the database is overloaded but still responding. A TTFB above 2 seconds reduces conversion by 7% per second.
Content validation. HTTP 200 does not guarantee the page is working. Bitrix may return 200 with a PHP Fatal Error message or an empty template. The checker searches for a keyword on the page (company name, menu fragment). No keyword — alert.
SSL certificate. Certificate expiration is a common cause of unavailability — 20% of all outages. Monitoring warns 14 and 7 days before expiration.
Domain. Similarly — warning about domain registration expiration.
Built-in Bitrix tools
The "System Check" module (bitrix:system.checker) is a one-time diagnostic, not continuous monitoring. It checks PHP version, MySQL version, settings, file permissions. Useful after updates, but not for ongoing observation.
The Performance Monitor (perfmon) logs SQL queries, page execution time, and load per hit. It is enabled at Settings → Performance → Monitor. Useful for analyzing slowdowns, but does not send alerts.
The Performance Panel gives a score (out of 100). It shows bottlenecks: slow disk, insufficient cache, suboptimal MySQL settings. A reference, but no replacement for external monitoring.
How to set up external monitoring?
Minimum configuration:
| Service |
What it checks |
Interval |
Alert |
| UptimeRobot (Free) |
HTTP status, TTFB |
5 min |
Email, Telegram |
| Hetrixtools (Free) |
HTTP + keyword |
1 min |
Email, Slack |
| Zabbix (Self-hosted) |
Everything |
30 sec |
Any channel |
Zabbix provides 10x more detailed metrics than UptimeRobot, but Hetrixtools offers 5x faster check intervals than the free UptimeRobot plan. A site uptime monitor ensures your online store is always accessible.
UptimeRobot is the minimum option. Free plan: 50 monitors, 5-minute interval. Add URLs for homepage, catalog, cart. For each, check HTTP 200 + keyword. Notifications via email and Telegram bot.
Hetrixtools is an advanced option. Free plan: 15 monitors, 1-minute interval, checks from multiple locations. Shows TTFB by geography.
Zabbix is for projects with their own infrastructure. It monitors not only HTTP but also server metrics (CPU, RAM, disk) in conjunction with site availability. Setup is more complex, but capabilities are unmatched.
Zabbix setup details
For Zabbix, deploy an external node in a different cloud region. Configure triggers for HTTP response code, TTFB, and content keyword. Use API integration for Telegram alerts with escalation to PagerDuty after 10 minutes of unacknowledged downtime.
Bitrix specifics
Agents. Bitrix's agent subsystem (b_agent) runs background tasks: 1C exchange, mailings, cleanup. If agents stop (CRON events handler fails or no hits to trigger on-hit agents), the site works but business processes stall. Monitoring: check the NEXT_EXEC date in b_agent — if the maximum lag exceeds 1 hour, agents are not running. Effective downtime prevention relies on proactive monitoring.
1C exchange. The file /bitrix/admin/1c_exchange.php handles exchange. If exchange hangs, the catalog stops updating but the site works. Monitor by the modification date of the exchange file (/upload/1c_exchange/) or by the timestamp of the last exchange log entry.
License. Bitrix with an expired license works but does not receive updates or security patches. Monitor license expiry via \Bitrix\Main\Config\Option::get('main', '~PARAM_MAX_SITES') or checking the license file.
Notification channels
Email is a basic channel but messages may be lost. Telegram is faster and more noticeable. Setup: create a bot via @BotFather, get a token, add the bot to a group or channel. In the monitoring service, specify the Telegram API webhook URL. For UptimeRobot, use the built-in integration in the Alert Contacts section.
Escalation: if an alert is not acknowledged within 15 minutes, escalate to a phone call. Services like PagerDuty and Opsgenie solve this, but for small projects, repeated Telegram notifications with increasing frequency suffice.
What's included in the work
- Audit of the current site and infrastructure state.
- Setup of external monitoring (UptimeRobot/Hetrixtools/Zabbix).
- Addition of checks for agents, SSL, domain, 1C exchange.
- Configuration of notification channels (Telegram, email, escalation).
- Documentation of monitoring scheme and instructions for your team.
- Support: adjusting thresholds, adding new metrics.
The average loss from a one-hour downtime of a Bitrix online store can range from $500 to $5,000 for a medium store. Our monitoring setup costs starting at $150, preventing such losses. Get a consultation: contact us for a cost estimate for your project.
| TTFB Threshold |
Description |
| < 1 s |
Excellent |
| 1-2 s |
Good |
| 2-5 s |
Warning |
| > 5 s |
Critical |
Source: Official 1C-Bitrix documentation on performance monitoring
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)
- Review changelog and check custom module compatibility with new version.
- Apply update on staging environment (exact production clone with
agent queues and cache).
- Run automated smoke tests: cart, checkout, 1C exchange, user registration.
- Deploy to production during low-traffic window.
- Monitor
error_log, /bitrix/admin/event_log.php, and key performance metrics for 2 hours.
- Roll back immediately if any anomaly appears (max 5 minutes).
Comparison: Monthly vs Quarterly Updates
| Metric |
Monthly Updates |
Quarterly Updates |
| Security vulnerability window |
< 30 days |
90+ days |
| Downtime risk |
Low (tested, incremental) |
Moderate (larger jumps) |
| Module compatibility issues |
Early detection |
Accumulated breaking changes |
| Client disruption |
Minimal (scheduled) |
May require emergency fixes |
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
| Parameter |
Start |
Business |
Pro |
| Hours per month |
up to 5 |
up to 15 |
up to 40 |
| Response time |
8 business hours |
4 business hours |
1 hour 24/7 |
| Monitoring |
Weekly |
Daily |
Real-time |
| Backups |
Weekly |
Daily |
Daily + incremental |
| Core updates |
Quarterly |
Monthly |
As released |
| Dedicated manager |
No |
Yes |
Yes |
| Report |
Monthly |
Monthly |
Monthly + analytics |
| Rollover hours |
No |
Within quarter |
Within half-year |
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.