Guide Errors & Troubleshooting

How to read a server error log

One log entry usually says more than an hour of guessing — here is where to find it and how to read what it is telling you.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

Almost every guide to a broken website eventually says "check the error log", as though that were self-explanatory. It usually isn't the first time. This is what the log actually is, where to find it, and how to read an entry once you have one in front of you.

What the error log actually is

When something fails on the server — a PHP script hits a fatal error, a database query fails, a file can't be found — the server writes a line describing exactly what happened to a text file, instead of, or in addition to, showing anything to the visitor. The public-facing page might just say "500 Internal Server Error" or show nothing at all; the log entry says precisely which file, which line, and which function was responsible.

This is deliberate. Showing the real detail to every visitor would leak file paths and sometimes credentials. The log is the same information, kept private.

Finding it

In your hosting control panel, look for a section named something like Error Logs, usually under a logs or diagnostics area. It lists recent entries for your site, generally with the newest at the top or bottom depending on the tool. If you can't locate it, our WordPress-specific logging is a separate setting covered below — the control panel log and the application's own log are not always the same file.

Two different logs, two different jobs

A server or PHP error log catches problems at the server level — fatal errors, syntax errors, out-of-memory conditions. An application log, such as WordPress's debug.log, is switched on separately and catches warnings and notices from within the application itself. If one is empty, check whether you're looking at the right one for the problem you have.

Reading an actual entry

A typical PHP fatal error looks like this:

[26-Aug-2026 14:32:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function
  wp_kses() in /home/site/public_html/wp-content/plugins/example/init.php:42
  Stack trace:
  #0 /home/site/public_html/wp-content/plugins/example/loader.php(18): example_init()
  #1 {main}
  thrown in /home/site/public_html/wp-content/plugins/example/init.php on line 42

Break it into its parts, in the order that matters:

The timestamp — confirms this entry matches when the fault actually happened, rather than being an old, already-fixed error still sitting in the log.
The error type — "Fatal error" stops the page dead. "Warning" and "Notice" are worth investigating but rarely explain a blank page or a 500 on their own.
The message — here, a function that doesn't exist was called. That usually means a required file wasn't loaded, or two plugins expect different, incompatible versions of something.
The file and line number — init.php:42 is exactly where to look. This is the single most useful piece of the entry.
The stack trace — reads bottom to top, showing what called what on the way to the failure. Useful when the file that broke was itself called from somewhere else, which is common in plugin and theme code.

Common message types and what they usually mean

Log message contains	Usual cause
Allowed memory size exhausted	The script ran out of the PHP memory limit — see raising it, or find what is consuming that much.
Maximum execution time exceeded	A script ran longer than the server allows, common with large imports or backups.
Call to undefined function / class	Required code never loaded — often a plugin conflict or an incomplete update.
Syntax error, unexpected token	A file was edited and saved with a mistake in it, or an upload was interrupted partway through.
Permission denied	The server tried to read or write a file it doesn't have the correct access to.
Connection refused / could not connect	Usually a database credential or availability problem.

Turning on more detail temporarily

If the log is empty or unhelpful, and the site is WordPress, you can get a much fuller picture by adding this to wp-config.php, above the line that says it has stopped editing:

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

This writes warnings and notices, not just fatal errors, to wp-content/debug.log, without showing anything on the public page — that's what WP_DEBUG_DISPLAY being false does.

Turn it back off once you're done

Debug logging left switched on accumulates a growing file with every visit and can slow the site slightly. Set WP_DEBUG back to false once you have the information you need.

If the log is completely empty

An empty log when the site is clearly broken usually means one of two things: the failure happened before PHP even started running — which points at .htaccess or file permissions rather than application code — or logging isn't enabled for the account. Ask support to confirm logging is switched on if you suspect the latter.

When you're ready to ask for help

Copy the exact entry — timestamp, message, file and line — rather than paraphrasing it. That single block of text is usually enough for support to identify the cause immediately, especially when paired with the URL and time the fault occurred. Our guide on reporting a problem so it gets fixed fast covers what else is worth including alongside it.