Is Currently Unable to Handle This Request: Debugging HTTP ERROR 500

A blank page saying your site is currently unable to handle this request means the application raised an error and the server suppressed the details. The actual error exists — in the server error log, or behind a display setting that is switched off in production for good reason.

This is the least informative error on the web, and deliberately so: showing a stack trace to a visitor leaks file paths, database names and sometimes credentials. So the page is empty and the information is somewhere else. Knowing where turns a mysterious outage into a two-minute fix.

Table of contents

• Find the log before changing anything
• Turning errors on temporarily, and safely
• The causes, in the order they actually occur
• A disciplined way through it
• How this fits the rest of the stack
• FAQ

Find the log before changing anything

The reflex is to start editing configuration. Read the log first — it usually names the file and line, and everything after that is mechanical.

# Common locations, in rough order of likelihood
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/apache2/error.log
tail -n 50 /var/log/php*-fpm.log
tail -n 50 ./error_log            # shared hosting often writes here

# Follow it while reproducing the request
tail -f /var/log/nginx/error.log

That last approach is the most efficient one available: watch the log, load the failing page, and read what appears. It removes all guesswork about which entry corresponds to your request.

On shared hosting the log is usually in the control panel, or an error_log file in the document root or the account’s home directory.

Note that with PHP-FPM behind nginx, the useful error is often in the FPM log rather than the nginx one — nginx only records that the upstream failed, which tells you nothing about why.

If you find nothing at all, the error may predate logging: a syntax error in a config file, or a permissions problem preventing the log itself from being written.

Turning errors on temporarily, and safely

When the log is unavailable, display the error briefly — never permanently, and never on a site with real visitors if you can avoid it.

<?php
// Top of the entry point, temporarily
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

For WordPress specifically, log to a file rather than to the screen, which keeps the details out of public view:

<?php
// wp-config.php, above the stop-editing line
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);      // writes to wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // and not to the browser

That combination is the right one: full detail, written to a file only you can read.

Turn it off when you are done. A site left with display errors on is a site publishing its absolute file paths, its database name, and occasionally fragments of queries containing data. That is genuinely useful reconnaissance for anyone probing you.

One caveat worth knowing: display_errors cannot show an error that occurs before PHP finishes starting up. A fatal error in a configuration file or an extension load failure produces a 500 with nothing displayed regardless of the setting, and only the server log will have it.

The causes, in the order they actually occur

1. A fatal PHP error. Calling an undefined function, a type error, or a syntax error in code deployed without being run. If the 500 started immediately after a deploy or a plugin update, this is almost certainly it.
2. Memory exhaustion. Allowed memory size exhausted in the log. Raise the limit as a temporary measure, then find what is consuming it — usually a query loading an entire table into memory rather than paginating.
3. A .htaccess directive the server does not support. A directive requiring a module that is not loaded produces a 500 on every request. Rename the file to test: if the 500 clears, the file is the cause.
4. File permissions. Directories should generally be 755 and files 644. A file the web server cannot read, or one that is world-writable, causes a refusal on some configurations.
5. A failed database connection. Wrong credentials, a database that is not running, or connection limits exhausted — the last of which produces a 500 that comes and goes with traffic, which is the most confusing version.
6. A timeout. The request exceeded the execution limit. Look for a slow query or an outbound call with no timeout of its own.
7. A broken upstream. With PHP-FPM or a reverse proxy, the pool being down or the socket path being wrong gives a 502 or 500 with an upstream error in the log.

The ordering question that narrows this fastest is simply: what changed? A site that worked yesterday and fails today failed because of something that happened in between — a deploy, an update, a certificate renewal, a disk filling, a credential rotating.

A disciplined way through it

When the log is unavailable and the cause is not obvious, bisect rather than guess.

1. Confirm it is server-side. Check the status code directly — curl -sI https://example.com — so you know you are debugging a 500 and not a client-side failure that looks similar.
2. Roll back the last change. If a deploy or an update preceded it, reverting is faster than diagnosing and tells you immediately whether you are in the right area.
3. Disable extensions or plugins as a group. For a CMS, rename the plugins directory. If the site returns, restore them one at a time until it breaks.
4. Switch to a default theme or template. Removes theme code from the picture in one step.
5. Check disk space. df -h. A full disk causes failures that look like anything at all, and it is quick to rule out.
6. Check the database is reachable from the application host, with the credentials the application is using rather than the ones you remember.

Step five is worth its place despite looking unrelated. A full disk prevents sessions being written, logs being appended and temporary files being created, producing a scattering of unrelated-looking errors — and it is one command to exclude.

And the meta-point: if diagnosing this required SSH access, a log file somebody had to find, and a plugin folder rename, the deployment setup is making a five-minute problem into an hour-long one.

How this fits the rest of the stack

A 500 with no detail is a monitoring problem as much as an application problem. The error was always there; the difficulty is that reaching it required knowing which machine, which directory, and which of four log files to open.

RunxBuild puts that in one place. A service in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploys from your GitHub repository, and the build log and the runtime logs sit together in the dashboard — so a release that compiled and then crashed on the first request is a visible log line rather than an SSH session. A bad release rolls back to the previous deploy in one step, which is the fastest available answer to what changed. Managed MySQL and Postgres run alongside with connection limits and backups, and managed WordPress adds a file manager and a database browser in the dashboard for the times the answer is in a file or a table. To see what a service and its database come to, the RunxBuild hosting calculator lists them as separate line items.

Useful related references:

• How to Connect Flask to a MySQL Database: The Minimum Code That Works, the Right Way to Handle Credentials, and Why SQLAlchemy Is Worth the Import
• HTTP Error 500 in WordPress: The Four Causes, in Order of Likelihood
• n8n HTTP Request Node: The Auth and Error Playbook
• Services on RunxBuild

FAQ

What does HTTP ERROR 500 actually mean?

That the application raised an unhandled error and the server returned a generic failure rather than the details. The page is deliberately blank, because a stack trace would reveal file paths, database names and sometimes credentials. The real message is in the server error log.

Where do I find the error behind a 500?

In the web server or interpreter error log — commonly under /var/log/nginx/, /var/log/apache2/, a PHP-FPM log, or an error_log file in the document root on shared hosting. The most efficient approach is to follow the log with tail -f while reloading the failing page.

How do I show the error on screen instead?

Enable display_errors and full error reporting temporarily, or for WordPress set WP_DEBUG and WP_DEBUG_LOG on with WP_DEBUG_DISPLAY off so details go to a file rather than the browser. Turn it back off afterwards — a site displaying errors publishes its file paths and database name.

Why is the page blank even with errors enabled?

Because errors occurring before the interpreter finishes starting up cannot be displayed by a runtime setting. A syntax error in a configuration file or a failed extension load produces a 500 with nothing on screen no matter what, and only the server log records it.

The site worked yesterday and fails today. Where do I start?

With whatever changed in between — a deploy, a plugin or dependency update, a rotated credential, a renewed certificate, or a disk filling up. Rolling back the most recent change is usually faster than diagnosing forward, and it immediately confirms whether you are looking in the right place.