Diagnosing and Resolving 500 Errors in 1C-Bitrix

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. Bitri
11+Years of work900+Completed projects100+In house employees19+Partners
Services we offer
Showing 1 of 1All 1626 services
Diagnosing and Resolving 500 Errors in 1C-Bitrix
Medium
~1-2 weeks

Our competencies:

Frequently Asked Questions

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:

  1. PHP error log — the path is determined by the error_log directive in php.ini or the php-fpm pool config. Typical locations: /var/log/php-fpm/www-error.log, /var/log/php/error.log.
  2. Web server log — for nginx: /var/log/nginx/error.log, for Apache: /var/log/apache2/error.log or /var/log/httpd/error_log.
  3. 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/syslog or dmesg for entries like Out of memory: Kill process or segfault.
Example Quick Isolation Create a test file `test500.php` with the contents: ```php

Determine 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.php calls 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_handling in .settings.php to write to a file — even with partial kernel initialization, this increases the chance of obtaining a stack trace.
  • Monitor memory_limit with 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.php allows updating from the CLI, simplifying rollback.

What's Included in the Work

  • Diagnostics: analysis of PHP and web server logs, checking .settings.php and .htaccess configuration, 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!

1C Bitrix presentation1C Bitrix24 presentation1C Enterprise presentation