Guide PHP & Development

How to read a PHP error log

The error log names the exact file and line that failed — here is where to find it and how to read what it is telling you.

iFastHosting Support Team Updated 26 August 2026 6 min read Beginner

When something in PHP fails, it writes a record of exactly what happened to a log file whether or not anything shows up in the browser. That record is almost always more useful than the on-screen error, because a blank page or a generic 500 tells a visitor nothing while the log entry names the file, the line, and the type of failure directly.

Where the log lives

On shared hosting, the error log is usually reachable in one of two ways:

The error log viewer in your control panel, which shows recent entries without needing file access at all. This is the fastest route for a quick look.
A log file inside your hosting account, commonly named something like error_log, or wherever the error_log ini directive points, viewable through the file manager or over SFTP/SSH.

If you cannot find one at all, logging may simply be off for that site — see the section below on turning it on.

Reading an entry

A typical line looks like this:

[26-Aug-2026 14:03:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function old_function() in /home/user/public_html/wp-content/plugins/example/example.php:42
Stack trace:
#0 /home/user/public_html/wp-blog-header.php(19): require()
#1 /home/user/public_html/index.php(17): require('...')
#2 {main}
  thrown in /home/user/public_html/wp-content/plugins/example/example.php on line 42

Read it in this order:

The timestamp. Confirms this is the entry for the request you are actually investigating, not an old one from earlier in the day.
The error type. "Fatal error" stopped execution outright. "Warning" and "Notice" did not, but are often the first sign of the same underlying problem — see the severity table below.
The message. Here, a function that no longer exists was called — a strong sign of a plugin that has not been updated for the PHP version currently running.
The file and line number, given as file.php:42 or "on line 42". This is the single most useful piece of information in the entry — it tells you exactly where to look rather than which file merely happened to be running at the time.
The stack trace, if there is one, shows how execution got there — useful when the failing line is inside a shared library called from several places and you need to know which caller triggered it this time.

Common error types and what they usually mean

Type	Usually means
Parse error	A syntax mistake — often a missing semicolon or unclosed bracket. See debugging a blank white page.
Fatal error	Execution stopped completely — an undefined function, a missing class, or an uncaught exception.
Warning	Something went wrong but PHP kept going — a missing file, a function called with the wrong argument type.
Notice / Deprecated	Usually harmless today, but a preview of what breaks outright on a future PHP version — worth clearing before an upgrade.

Watch the log live while you reproduce the problem

If your plan includes SSH access, tailing the file while you trigger the error again is far quicker than reloading a log viewer after the fact:

tail -f ~/logs/php_errors.log

Trigger the problem in another browser tab and watch the new line appear in real time, then press Ctrl+C to stop watching once you have what you need.

Turning logging on if there is nothing there

If the log is empty even though the site is clearly failing, logging itself may be off. Two directives control this, and they are independent of each other:

log_errors = On
error_log = /home/youraccount/logs/php_errors.log

Set these through the PHP settings area of your control panel or in a user-level php.ini. This is different from turning display_errors on, which prints errors to the page instead of a file — the two can be used together while you debug, but only file logging is safe to leave on for a live site, since display_errors shows visitors your file paths and code structure.

Log files grow — keep an eye on disk usage

A site producing a steady stream of warnings can build a surprisingly large log file over time. If disk space is unexpectedly tight, check the size of your error logs, and treat a log that never stops growing as a sign a warning needs fixing rather than just archiving.

What to do with what you find

Once you have a file and line number, that is usually enough to know whether the fix is yours to make — custom code — or a plugin or package update you need to apply. If the message points at a 500 response specifically, what causes a 500 error in PHP walks through the most common underlying causes in the order worth checking them.