When a page shows a blank screen or a bare "500 Internal Server Error", the useful message is almost never on the page. It is in the error log, a plain text file where the web server and PHP write down what they complained about and when. The browser is told as little as possible on purpose, because detailed errors shown to strangers help attackers more than they help you.
Reading a log looks intimidating the first time, mostly because of the volume. Most of it is irrelevant. The skill is knowing which line to look at, which words in it carry the meaning, and which lines to ignore. That takes about ten minutes to learn and saves hours, and the method is the same on a small shared plan as on a server you run yourself.
This article covers where the logs live, how to take a single line apart, what the common messages usually mean, and a repeatable routine for working from symptom to fix without guessing.
Where the logs live
In a hosting control panel, look for a section called "Errors", "Logs" or "Error log". Some panels show the last 50 or 100 lines in the browser, others let you download the file. On shared hosting that is usually all the access you get, and it is enough for most problems.
On a VPS or dedicated server the web server has its own error log, and PHP may have a separate one. Typical locations are shown below. They vary by distribution and by how the server was set up, so treat them as starting points rather than promises.
| Log | Typical path | What goes in it |
|---|---|---|
| Apache error log | /var/log/apache2/error.log or /var/log/httpd/error_log | Server errors, PHP errors when PHP runs inside Apache, permission problems |
| nginx error log | /var/log/nginx/error.log | Upstream failures, missing files, configuration problems |
| PHP-FPM log | /var/log/php8.2-fpm.log (version in the name) | Pool start-up, children killed, slow requests |
| Per-site log | ~/logs/ or /home/user/logs/ | Often a copy of the above, filtered to your domain |
| WordPress debug log | wp-content/debug.log | PHP notices, warnings and fatals from WordPress code, when enabled |
WordPress can write its own log when WP_DEBUG_LOG is switched on in wp-config.php. Do that on a staging copy where you can, and turn it off afterwards, because the file can grow large and, if it sits in a web-readable folder, anyone who guesses the address can read it.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );The third line matters: it stops errors being printed into the page itself while still writing them to the file.
Taking one line apart
A typical entry looks like this:
[05-Oct-2026 14:02:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function foo() in /home/user/public_html/wp-content/plugins/some-plugin/main.php:142It has five parts, and each answers a different question.
The timestamp lets you match the line to something you did. The severity tells you whether to care. The message says what went wrong. The path and line number say where. Here the path contains wp-content/plugins/some-plugin/, so the plugin is at fault, and renaming that folder over FTP or the file manager (which makes WordPress deactivate it) should bring the site back.
Severity is worth a moment. Notices and deprecation warnings are usually noise: code that works but is untidy. Warnings are worth a glance. Fatal errors are what break pages, and they are the ones to chase first.
Common messages and what they usually mean
The same dozen messages account for most tickets. This is a rough guide, not a verdict. The cause is sometimes one step removed from the words.
| Message | Usual meaning | First thing to try |
|---|---|---|
| Allowed memory size of 134217728 bytes exhausted | A script used more memory than PHP's limit (here 128 MB) | Find which plugin or import triggered it; raise memory_limit only after that |
| Maximum execution time of 30 seconds exceeded | A script ran too long | Look for an import, backup or slow remote call |
| Permission denied | File ownership or mode is wrong | Check who owns the file and whether the web user can read it |
| Primary script unknown / File not found | The web server and PHP disagree about a path | Check the document root and the PHP handler setting |
| Too many connections | The database is saturated | Look for runaway requests or bots; see the limits article in this series |
| Call to undefined function | Code is missing or an extension is not loaded | Check the PHP version and enabled extensions |
One caution on memory: raising the limit hides a leak without curing it. If a page needs 400 MB to render, something is wrong with the page.
A worked example
A small shop reports that the checkout page returns a white screen since Monday. Nothing was knowingly changed. The error log, read from the bottom, shows this:
PHP Warning: Undefined array key "currency" in .../themes/shopfront/functions.php on line 88
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in .../plugins/stock-sync/sync.php on line 311The warning is old and shows up all day, so it is noise. The fatal appears only when checkout loads. The path points at a stock-sync plugin. Disabling it restores checkout, and a look at its settings shows a nightly sync that had been changed to run on every page view. Setting it back to nightly fixes the cause. Raising memory would only have delayed the next white screen.
Notice what made this quick: reading the newest fatal first, ignoring the repeated warning, and following the path.
A workflow you can repeat
- Open the log in a second window and, if you have shell access, run
tail -f error.logso new lines appear as they happen. - Reproduce the problem once, deliberately. Load the failing page.
- Note the first error after your action. Later ones are often consequences of the first.
- Search for the exact message text, minus the site-specific paths.
- Change one thing, retest, and write down what you changed.
- If the answer is not visible, send your host the URL, the time to the minute and the time zone. They can see server-level lines that your panel hides.
Error log or access log?
Servers keep two kinds of log, and people open the wrong one often enough to be worth separating them. The error log records what the software complained about. The access log records every request, one line each, whether it succeeded or not.
203.0.113.25 - - [05/Oct/2026:14:02:11 +0000] "GET /checkout/ HTTP/2.0" 500 1843 "-" "Mozilla/5.0"That line tells you who asked (the address), when, what for, and the status code the server answered with (500 here). It does not say why. Use the access log to find out which requests fail and how often, then take the timestamp to the error log to find the reason. If the access log shows a 500 at 14:02:11 and the error log has a fatal at 14:02:11, you have your pair. If the access log shows 404s for files you know exist, the problem is paths or rewrite rules rather than code.
A burst of requests to /xmlrpc.php or /wp-login.php from one address is a different story: that is a bot, not a bug, and the fix lives in a firewall or rate limit rather than in your site.
What changes between hosting types
On shared hosting you see your own account's log only, usually trimmed to recent lines, and you cannot change server-wide settings. Many hosts let you set PHP options per site, which is where memory and time limits live. On a VPS you can read everything, but you are also responsible for rotating logs so they do not fill the disk. On managed WordPress plans the panel often shows a curated error view and keeps the raw log from you, which is tidy until you need something it filtered out. Ask support for the raw lines in that case.
Log rotation deserves a note. A site that has run for years may have an error log of several gigabytes, mostly the same warning repeated. Fix or silence the repeated line and the useful ones become visible again.
Look at your own configuration
With shell access, three commands cover most of it:
tail -n 50 error.log
grep -i "fatal" error.log | tail -n 20
grep "14:02" error.logThe first shows the latest entries. The second pulls only the fatals. The third narrows to a minute you know something happened. Without shell access, download the file from the panel and search it in any text editor. For wider troubleshooting, see the troubleshooting guide, and for what the numeric codes in access logs mean, the HTTP status code list.