ServerBorn - Reading Server Error Logs: From White Screen to Root Cause

A white screen on your WordPress site is not a diagnosis, it is a symptom. Something threw a fatal error and PHP stopped rendering, but the page itself will not tell you what broke. The answer is almost always sitting in a log file a few directories away. This guide walks through where those logs live, how to turn on the logging WordPress already has built in, and the five error patterns that account for the large majority of outages.

Where the Logs Actually Live

Most WordPress installs on a LiteSpeed or Apache stack have at least three log sources worth checking, in this order:

PHP error log: usually named php_errors.log or configured via error_log in php.ini. This is where fatal errors, warnings, and notices from PHP itself land, including the exact file and line number.
Web server log: LiteSpeed and Apache write access and error logs separately, often under a path like /logs/ or inside your hosting control panel’s log viewer. This is where you find 500, 502, and 504 responses along with timestamps.
WordPress debug log: WordPress can write its own log via WP_DEBUG_LOG, landing in wp-content/debug.log by default. This captures deprecation notices and plugin-level warnings that PHP’s own log may not surface as clearly.

If you have shell access, wp-cli makes finding and tailing these fast:

wp config get WP_DEBUG_LOG
tail -f wp-content/debug.log

On a managed LiteSpeed host, your control panel typically exposes a log viewer so you do not need raw shell access at all. That is one of the things a host like ServerBorn handles for you: a clean, searchable view into PHP and server logs without hunting for file paths.

Turn On WordPress’s Own Logging

If debug.log is empty or missing, add these lines to wp-config.php above the line that says “That’s all, stop editing”:

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

WP_DEBUG_DISPLAY set to false is important on a live site. It keeps errors out of the visitor-facing page while still writing them to the log. Reproduce the issue, then check wp-content/debug.log for a fresh entry with a timestamp matching your test.

Five Error Patterns That Cover Most Outages

1. Blank White Screen with No Visible Error

This is a fatal PHP error with display turned off, which is the correct production setting but leaves you staring at nothing. Check the PHP error log first. You are looking for a line starting with PHP Fatal error: followed by a message like Uncaught Error: Call to undefined function and a file path. That file path tells you exactly which plugin or theme file caused the crash.

2. “Allowed memory size exhausted”

This reads as Allowed memory size of X bytes exhausted and means a script tried to use more memory than PHP’s memory_limit allows. It usually shows up after installing a plugin that does heavy processing (image manipulation, PDF generation, large imports) or after a plugin update introduces a memory leak. Raising the limit in wp-config.php with define( 'WP_MEMORY_LIMIT', '256M' ); can mask the symptom, but if the number keeps climbing, the real fix is finding which plugin is consuming the memory, often by deactivating plugins one at a time and watching the log.

3. “Call to undefined function” or “Class not found”

This almost always means a PHP version mismatch or a broken update. A plugin written for an older PHP release may call a function that no longer exists, or a plugin update expects a newer PHP feature than your server is running. Since PHP 8.1 through 8.3 is the current mainstream, and 8.3 with OPcache is a solid default, check your site’s PHP version and confirm the plugin in question lists that version as supported. Also check for a partial update: if a plugin’s files got interrupted mid-upload, some files reference classes that others never finished writing.

4. 500, 502, or 504 Errors in the Server Log

A 500 Internal Server Error is broad and often traces back to a corrupted .htaccess file, a PHP timeout, or a fatal error the PHP log will confirm. A 502 Bad Gateway or 504 Gateway Timeout usually means the web server could not get a timely response from PHP itself, often because a script (an import, a bulk plugin action, a poorly optimized query) ran long enough to hit a timeout limit. If you see 504s clustering around a specific admin action, that action is the culprit, not the server.

5. Database Connection Errors

“Error establishing a database connection” in the browser corresponds to a MySQL or MariaDB connection failure in the server log, commonly from wrong credentials in wp-config.php after a migration, a database server that has hit its connection limit, or (less often) a corrupted table. Check the database credentials first, since a copy-paste error during a site move is the single most common cause. If credentials are correct, check whether the database server itself is under load from too many simultaneous connections, which points to a caching gap rather than a WordPress bug: a properly configured object cache using Redis or Memcached takes repetitive queries off the database entirely and often resolves this class of error on its own.

Reading a PHP Stack Trace in 30 Seconds

A typical fatal error entry looks like this:

PHP Fatal error:  Uncaught Error: Call to undefined function old_helper() in /wp-content/plugins/example/inc/helpers.php:42
Stack trace:
#0 /wp-content/plugins/example/example.php(88): do_thing()
#1 /wp-includes/class-wp-hook.php(324): example_init()
#2 {main}
  thrown in /wp-content/plugins/example/inc/helpers.php on line 42

Read it top to bottom: the first line names the error and the exact file and line where it happened. The stack trace below shows the chain of function calls that led there, read from the top (where it broke) down. You rarely need to read past the first two or three lines. In this example, the plugin “example” is calling a function that does not exist, which is a strong signal the plugin needs an update or is incompatible with your current PHP version.

When Cloudflare Is in the Mix

If your site sits behind Cloudflare, a visitor-facing error page (a Cloudflare-branded 502 or 504) usually means the origin server itself is slow or down, not that Cloudflare’s edge is at fault. In that case, the server-level and PHP logs on your origin are still the right place to look. Cloudflare’s own dashboard can confirm whether requests are reaching your origin at all, which helps you rule out edge-level causes before digging into PHP.

Takeaway

A white screen or a gateway error is never the end of the investigation, it is the starting point. Turn on WordPress’s debug log, check the PHP error log for the exact file and line, and match what you find against these five patterns: fatal errors, memory exhaustion, undefined functions from version mismatches, gateway timeouts from slow scripts, and database connection failures. Nine times out of ten, the log tells you precisely which plugin or setting to fix, no guessing required.

← All posts