HTTP 500 Internal Server Error: what it means and how to troubleshoot

A website returning "500 Internal Server Error" gives no useful information to those trying to fix it. Unlike 502 (bad gateway, upstream server not responding), 503 (service unavailable, often due to overload or maintenance), or 504 (gateway timeout), 500 is the generic catch-all: something broke during script execution, but the message shown in the browser doesn't explain what. To find out, you need to open the server logs.

Where to look first

In order, before changing anything:

1. The plugin or theme installed most recently. If the 500 error appeared right after an update or installation, disable it via FTP by renaming the folder in wp-content/plugins/ (for example, adding _disabled to the name): if the site comes back up, you've found the culprit without reading a single log.
2. The .htaccess file, if your site runs on Apache. A poorly written rewrite rule or a required module that's not available will crash the entire site. Rename it temporarily and try reloading WordPress—it will regenerate the standard one from the panel.
3. The PHP log, which almost always contains the real reason for the crash (fatal error, out of memory, missing function).
4. The web server log (NGINX or Apache), which sometimes catches PHP-FPM errors before they even reach the application log.

Log paths: they vary by system and control panel

There is no single path that works everywhere. On a plain Linux server it depends on the distribution; on a server with a control panel it depends on the panel.

Environment	NGINX log	PHP-FPM log
Ubuntu / Debian (standard packages)	/var/log/nginx/error.log	/var/log/php8.3-fpm.log (the version is in the filename)
AlmaLinux / Rocky / RHEL	/var/log/nginx/error.log	/var/log/php-fpm/error.log for the service, /var/log/php-fpm/www-error.log for site errors
DirectAdmin	/var/log/nginx/domains/ (per domain)	/usr/local/php83/var/log/php-fpm.log

One detail that throws many people off: the PHP-FPM service log (/var/log/php8.3-fpm.log on Ubuntu) only records process events, not errors from your site's code—for example, a notice when the pool reaches pm.max_children. Actual PHP errors, if the pool doesn't have a dedicated error_log configured, end up in the NGINX log with the prefix "FastCGI sent in stderr".

Commands verified on Ubuntu 24.04 (NGINX + PHP-FPM 8.3)

To follow an error as you reproduce it:

sudo tail -f /var/log/nginx/error.log

If a dedicated log is set for the PHP-FPM pool (file in /etc/php/8.3/fpm/pool.d/), with a line like:

php_admin_value[error_log] = /var/log/php8.3-fpm/site.log
php_admin_flag[log_errors] = on

after saving, reload the service:

sudo systemctl reload php8.3-fpm

Enable WordPress debugging to see the real error message

The most direct way to find out why WordPress is returning a 500 error is to open wp-config.php and modify (or add, before the "That's all, stop editing!" line) these three lines:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

With WP_DEBUG_DISPLAY set to false, errors won't show on the public page (which you should avoid on a production site visible to users), but they'll be written to a file. By default the file is wp-content/debug.log; if you want a different path you can replace true with an absolute path, for example define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );.

Once you've reproduced the error, just read the last few lines:

tail -n 50 wp-content/debug.log

After checking, those three lines should go back to false: leaving debugging active on a public site exposes installation details to anyone who finds the file, if it accidentally ends up in a directory accessible from the browser.

When it's the server, when it's the code

If the PHP log shows a fatal error with a function name, class, or theme/plugin file, the problem is in the code: it needs updating, replacing, or reporting to whoever maintains it. If the NGINX or PHP-FPM log instead shows file permission errors, pool timeouts, or the PHP-FPM process restarting on its own, the problem is server-side: pool configuration, disk space exhausted, or memory limits set too low in php.ini. A quick check of free space (df -h) and available memory (free -m) before opening any log helps you avoid hunting through code for a problem that's just a lack of resources.