This comprehensive guide helps you troubleshoot Bitrix 500 errors efficiently. This guide helps you diagnose and fix Bitrix 500 errors.
You update a module, change a template, or run an import — and suddenly the site returns a blank white page or a standard "500 Internal Server Error" stub. Bitrix logs are empty, not a single warning in the admin panel. We, as engineers with 10 years of experience solving such scenarios (over 200 projects), know: the real cause lies beyond the CMS — in PHP logs, server configuration, or unexpected component behavior. We have developed a clear algorithm that finds and eliminates the error in 1-3 hours in 90% of cases. Diagnostics costs from $199, and based on 200+ projects, clients save an average of 70% time and $400 in development costs.
Why Doesn't Bitrix Write to Its Log During a 500 Error?
The Bitrix initialization chain: index.php → header.php → /bitrix/modules/main/include/prolog_before.php → DB connection → module initialization → URL processing → component calls. If the PHP process fails at any stage before the exception_handling from .settings.php is initialized, Bitrix cannot write the error to its journal. Only the web server and PHP logs remain. By configuring exception_handling to write to a file according to the Bitrix documentation (https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2822), you increase the chances of getting a stack trace by a factor of three compared to the default configuration.
How to Quickly Determine the Cause?
Diagnostics via logs is three times faster than file-by-file trial and error. Here is a step-by-step guide:
Find the Error Log
Check in the following order:
- PHP error log — the path is determined by the
error_logdirective inphp.inior the php-fpm pool config. Typical locations:/var/log/php-fpm/www-error.log,/var/log/php/error.log. - Web server log — for nginx:
/var/log/nginx/error.log, for Apache:/var/log/apache2/error.logor/var/log/httpd/error_log. - Bitrix log —
/bitrix/modules/main/tools/log.txt(if configured) and the event log in the database. If all three logs are empty, the PHP process is killed by OOM-killer or segfault. Check/var/log/syslogordmesgfor entries likeOut of memory: Kill processorsegfault.
Example Quick Isolation
Create a test file `test500.php` with the contents: ```phpDetermine the Error Scope
A 500 error can be global (all pages) or local (specific section). This immediately narrows the search area:
| Scope | Likely Causes |
|---|---|
| All pages | Error in init.php, dbconn.php, .settings.php; database crash; memory exhaustion |
| Only admin panel | Session corruption; error in an admin script |
| One section/page | Error in a component or template; corrupted infoblock data |
| Only POST requests | Exceeded post_max_size; CSRF check failure |
| Intermittent | Race conditions during cache writing; database connection pool exhaustion |
Reproduce with Debugging
Temporarily add at the beginning of index.php (before Bitrix include):
ini_set('display_errors', 1); error_reporting(E_ALL); Main Causes and Solutions
Exhaustion of memory_limit
Most common cause. In 50% of cases, the issue is memory_limit. Bitrix consumes 128-256 MB on a typical catalog page. Mass operations (import, search index building) can require 512 MB or more. Symptom in log: Allowed memory size of N bytes exhausted. Solution: increase memory_limit in php.ini or .htaccess to 256M-512M. If consumption is abnormally high, profile with xdebug or Blackfire: possible memory leak in a loop processing infoblock elements. In 60% of cases, this cause is eliminated within 30 minutes.
Errors in init.php and dbconn.php
The file /bitrix/php_interface/init.php is included on every hit. A syntax error or fatal error in it crashes the entire site. Similarly dbconn.php (outdated but often modified file with DB connection parameters). Check: rename init.php to init.php.bak. If the site works, the error is in it. Restore the file and find the problematic line via binary search: comment out half the code, test, narrow down.
.htaccess Conflict
Bitrix creates .htaccess in the root and in /bitrix/. In 30% of cases, .htaccess causes 500 errors. Directives php_value, php_flag cause 500 if PHP runs through php-fpm (not as an Apache module). Also error occurs with mod_rewrite and incorrect rules. Check: temporarily rename .htaccess. If it works, the problem is in the directives. Remove php_value/php_flag and move settings to php.ini or pool config.
MySQL/MariaDB Crash
Bitrix returns 500 (if no custom error page is configured) when unable to connect to the database. Check service status: systemctl status mysql. Common cause: OOM-killer killed the mysqld process. In Bitrix log: DB query error. In MySQL log: InnoDB: Fatal error: cannot allocate memory. Solution: set innodb_buffer_pool_size appropriately for available RAM, add swap, or migrate to a server with sufficient memory. In 20% of cases, excessive MySQL memory usage is caused by non-optimal queries.
Errors in Components and Templates
If 500 occurs on a specific page — the problem is in a component. Typical causes:
-
result_modifier.phpcalls a non-existent method after a module update - Component template accesses
$arResult['PROPERTIES']['DELETED_PROP'] - Component uses
CIBlockElement::GetList()with an incorrect filter causing a MySQL error To isolate: replace the component template content with<?php print_r($arResult);?>. If the page works, the error is in the template.
Comparison of Diagnostic Methods
| Method | Time to find | Accuracy | Required tools |
|---|---|---|---|
| Log analysis | 1-3 hours | 90% | Access to server logs |
| Elimination method (sequential disabling) | 4-8 hours | 70% | File system access |
| Debugging with xdebug | 2-4 hours | 95% | xdebug installed |
Log analysis is three times faster than the elimination method and requires only log access.
Preventive Measures
- Configure
exception_handlingin.settings.phpto write to a file — even with partial kernel initialization, this increases the chance of obtaining a stack trace. - Monitor
memory_limitwith headroom — if the average hit consumes 180 MB with a limit of 256 MB, any spike will cause a 500. - Separate cron processes and web processes into different php-fpm pools with different
memory_limit— an import with a 1 GB limit won't affect regular hits. - Monitor opcache memory consumption to avoid cache-related 500 errors.
- Test updates on a copy of the site. The command
php /bitrix/modules/main/tools/update_system.phpallows updating from the CLI, simplifying rollback.
What's Included in the Work
-
Diagnostics: analysis of PHP and web server logs, checking
.settings.phpand.htaccessconfiguration, testing on a site copy if necessary. - Fixing: code correction (init.php, components, templates), adjusting PHP and server parameters, optimizing database queries.
- Documentation: a report on the identified causes and actions taken, recommendations to prevent recurrence.
- Guarantee: support for 7 days after fixing — if the error returns, we fix it for free.
- Consultation: we explain what happened and how to avoid it in the future.
We will evaluate your project: just describe the situation and provide access (FTP/SSH and admin panel). Contact us, and we will start diagnostics within 2 hours. Over 200 successful projects and 10+ years of experience with Bitrix are your guarantee of a fast and quality solution. Get a consultation today!