HTTP 500 internal server error: what it means and how to fix it

A 500 internal server error means the server encountered something unexpected and could not complete the request. It is the most generic error in the HTTP specification – the server knows something went wrong, but the error message does not tell you what. The actual cause is buried in server logs, and finding it is the entire challenge.

The 500 error is a server-side error, not a client-side error. The browser sent a valid request. The server accepted it and started processing it. Then something failed during processing – a PHP script crashed, a configuration file had a syntax error, a database connection dropped, or the server ran out of resources. The server cannot return the result, so it returns a 500 status code instead.

This guide covers the most common causes of 500 errors across web servers, PHP applications, and WordPress, how to find the actual error behind the generic message, and how to fix each scenario.

What a 500 error looks like#

Different web servers and browsers display 500 errors differently:

• Nginx: “500 Internal Server Error” on a plain white page
• Apache: “Internal Server Error – The server encountered an internal error or misconfiguration”
• Chrome: “This page isn’t working – HTTP ERROR 500”
• WordPress: “There has been a critical error on this website” (since WordPress 5.2)
• API responses:  {"error": "Internal Server Error"}  or  {"status": 500}

In all cases, the HTTP response code is 500, and the browser or API client receives no useful content. The page you requested was not generated.

500 vs 502 vs 503 vs 504#

These server error codes are related but have different causes. Understanding the difference helps you troubleshoot faster.

500 Internal Server Error – the server itself had an error while processing the request. The application code crashed, the configuration is broken, or the server hit a resource limit. The problem is inside the server that received the request.

502 Bad Gateway – a reverse proxy or load balancer received an invalid response from the upstream server. Nginx got a response from PHP-FPM, but the response was malformed or the connection was reset unexpectedly. The problem is in the communication between two servers (or between the web server and PHP).

503 Service Unavailable – the server is temporarily unable to handle the request. Usually because the server is overloaded, undergoing maintenance, or a backend service (like PHP-FPM) is down. The server is running but cannot process requests right now.

504 Gateway Timeout – the reverse proxy waited for a response from the upstream server and gave up. PHP-FPM is processing the request but took too long. The request is probably still running, but the proxy timed out waiting for it.

A 500 error means the server tried and failed. A 502 means the upstream response was invalid. A 503 means the server cannot try right now. A 504 means the server tried but the backend took too long. Each points to a different layer of the stack.

Finding the actual error#

A 500 error is a symptom, not a diagnosis. The actual error is in the logs.

Check the web server error log

Nginx:

tail -50 /var/log/nginx/error.log

Nginx logs the upstream error that caused the 500. Look for lines with [error] near the timestamp when the error occurred:

2026/04/08 14:23:15 [error] 1234#0: *5678 FastCGI sent in stderr:
"PHP Fatal error: Uncaught Error: Call to undefined function custom_init()
in /var/www/html/wp-content/plugins/broken-plugin/init.php:12"

This tells you exactly what crashed – a PHP fatal error in a specific plugin file at a specific line number.

Apache:

tail -50 /var/log/httpd/error_log

Or, depending on the distribution:

tail -50 /var/log/apache2/error.log

Check the PHP error log

If the web server error log does not contain the details, the PHP error log usually does:

tail -50 /var/log/php-fpm/error.log

The path varies by server configuration. To find it:

php -i | grep error_log

For a complete guide to finding and reading PHP error logs, see PHP error logging: how to log errors to a file.

Enable error output temporarily

If you cannot find the error in the logs, you can temporarily enable PHP error display to see the error in the browser. Add this to the top of the PHP file that is crashing, or to php.ini :

display_errors = On
error_reporting = E_ALL

This shows PHP errors directly in the browser. Do not leave this on in production – it exposes file paths, database details, and server information to visitors. For the full guide on safely enabling error display, see how to display PHP errors and enable error reporting.

For WordPress specifically, use wp-config.php debug constants instead:

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

This writes errors to wp-content/debug.log without exposing them to visitors.

The most common causes#

PHP fatal error

The most frequent cause of a 500 error on any PHP-powered site. A fatal error means PHP encountered something it cannot recover from: calling an undefined function, running out of memory, a syntax error, or a type error.

Fatal error: Uncaught Error: Call to undefined function get_custom_data() in /var/www/html/app/lib/data.php on line 42

How to fix: Read the error message. It tells you the file and line number. Fix the code at that location. If the error is in a WordPress plugin, the fastest fix is to deactivate the plugin. Rename its directory via SSH or SFTP:

mv wp-content/plugins/broken-plugin wp-content/plugins/broken-plugin-disabled

For the full WordPress-specific troubleshooting guide, see WordPress 500 internal server error.

PHP memory exhaustion

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes)

PHP ran out of memory during execution. This commonly happens during image processing, large database imports, or when a plugin loads too much data into memory.

How to fix: Increase the PHP memory limit in php.ini :

memory_limit = 256M

Or in WordPress via wp-config.php :

define('WP_MEMORY_LIMIT', '256M');

If increasing the limit does not help, a script is consuming excessive memory and the code needs to be fixed, not just given more room. See WordPress PHP memory exhausted error for diagnosing the root cause.

.htaccess syntax error (Apache)

On Apache servers, .htaccess files modify server behavior per directory. A syntax error in .htaccess causes a 500 error for every request to that directory and its subdirectories.

/var/log/httpd/error_log:
[core:alert] [pid 1234] /var/www/html/.htaccess: Invalid command 'RewriteRul', perhaps misspelled

How to fix: Rename the .htaccess file to test if it is the cause:

mv .htaccess .htaccess.broken

If the site loads after renaming, the error is in .htaccess . Fix the syntax error, or in WordPress, regenerate the file by going to Settings > Permalinks and clicking Save.

Nginx misconfiguration

Nginx does not use .htaccess files, but configuration errors in nginx.conf or site-specific config files can cause 500 errors. The most common causes are incorrect fastcgi_pass directives (pointing to a PHP-FPM socket that does not exist), missing try_files directives, and syntax errors after a config edit.

How to fix: Test the configuration before reloading:

sudo nginx -t

If the test fails, it tells you exactly which file and line has the error. Fix it, test again, then reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

File permission problems

If PHP cannot read a file it needs, or cannot write to a directory it needs to write to, the result is often a 500 error. This commonly happens after a migration, a backup restoration, or a manual file upload that changed ownership.

PHP Warning: require(/var/www/html/wp-config.php): Failed to open stream: Permission denied

How to fix: Check and fix file ownership and permissions. On a typical web server, files should be owned by the web server user and have standard permissions:

chown -R www-data:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

For the full guide to Linux file permissions and common permission problems, see Linux file permissions: chmod and chown explained.

Disk full

When the server’s disk is full, PHP cannot write temporary files, session files, or log entries. This can cause 500 errors that appear to have no cause – the error log might not even have an entry because PHP cannot write to it.

How to fix: Check disk usage:

df -h

If any filesystem is at 100%, free space immediately. Truncate large log files, remove old backups, or clear package caches. See how to check disk space in Linux for a complete guide to finding and resolving disk space problems. Also check for inode exhaustion – the disk can appear to have free space while being out of inodes.

Database connection failure

If the application cannot connect to the database during a request, some frameworks return a 500 error. WordPress shows its own specific “Error establishing a database connection” message for this case, but other PHP applications may return a generic 500.

How to fix: Verify the database server is running:

systemctl status mysqld

Check the database credentials in the application configuration. Test the connection manually:

mysql -u app_user -p app_database

If MySQL is running but connections are failing, it may be at its connection limit. See MySQL too many connections for diagnosing connection pool exhaustion. If the database server was recently restarted or crashed, check its status with systemctl:

journalctl -u mysqld -n 30

This shows the most recent MySQL log entries, which usually explain why it stopped or failed to accept connections.

Timeout or execution limit

If a PHP script exceeds the maximum execution time, it is killed. Depending on the server configuration, this can produce a 500 error (if PHP terminates abruptly) or a 504 gateway timeout (if the web server gives up waiting).

Fatal error: Maximum execution time of 30 seconds exceeded

How to fix: For legitimate long-running operations (imports, migrations, bulk processing), increase max_execution_time in php.ini . For normal page loads that should not take 30 seconds, find and fix the slow operation – usually a database query without an index or an external API call that hangs.

Elementor and page builder 500 errors#

Page builders like Elementor are a common source of 500 errors because they process large amounts of data during save operations. When you save an Elementor page, the editor sends a large POST request containing the entire page structure as JSON. If PHP’s max_input_vars , post_max_size , or memory_limit are too low, the save fails with a 500 error.

How to fix: Increase these PHP settings:

max_input_vars = 10000
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300

If the 500 error only happens on specific pages, the page may have too many elements or a widget that triggers a PHP error. Enable WordPress debug logging and check wp-content/debug.log after triggering the error.

API requests returning 500#

When an API endpoint returns a 500 status code, the error is on the server side. The client sent a valid request, and the server failed to process it. Common causes:

• Unhandled exceptions in the API code
• Invalid data that the API did not validate before processing
• Database errors triggered by the API operation
• Rate limiting or resource exhaustion on the server

Check the server’s error log for the specific exception. The 500 response body may also contain error details – inspect it with:

curl -v https://api.example.com/endpoint

The -v flag shows the full response headers and body, which may include an error message or stack trace (depending on the API’s error handling configuration).

Preventing 500 errors#

Most 500 errors are preventable with basic practices:

• Test configuration changes before applying them.  nginx -t ,  apachectl configtest , and  php -l filename.php  catch syntax errors before they reach production.
• Monitor disk space and memory. A simple alert script that checks  df -h  on a schedule catches disk-full situations before they cause downtime.
• Keep PHP error logging enabled. Even when  display_errors  is off,  log_errors  should always be on. Every 500 error should produce a log entry you can investigate. See PHP error logging for configuration.
• Update software regularly. Outdated PHP, outdated plugins, and outdated WordPress accumulate bugs and incompatibilities that cause crashes.

500 errors on Hostney#

On Hostney, each WordPress account runs in an isolated container with its own PHP-FPM instance, error logs, and resource limits. A 500 error on your site does not affect other accounts on the server.

PHP error logs are available in the control panel under your site’s log section. You can also access them via SSH through the Terminal Access section. The most common cause of 500 errors on Hostney is a plugin that crashes after an update – check the PHP error log for the specific fatal error, and deactivate the plugin if needed.

PHP settings like max_execution_time , max_input_vars , and post_max_size are configurable through Hosting > PHP Manager. Changes take effect immediately without needing to restart services manually. Note that memory_limit is set at the platform level and is not user-configurable – contact support if you need it adjusted.