How to Find and Fix PHP Errors (Logs and Debugging)

A blank white page, a sudden 500 error, or a site that half-loads are all usually caused by a PHP error – and the message that explains it is written to a log, even when nothing shows on screen. Knowing where to look turns “my site is broken” into a specific line you can act on. This guide shows how to read your PHP error logs on every JetHost WordPress hosting plan, how to switch on error messages safely while you’re testing, and the first things to check.

Why errors are often invisible

On a live site, PHP is set not to print errors to the screen – and that’s deliberate. An error message can reveal file paths and other details that help an attacker, so showing them to every visitor would be a security risk. Instead, PHP quietly records each error in a log file. That’s why a broken page can look completely blank: the explanation exists, it’s just written to the log rather than displayed.

Find the error log in cPanel

1. Log in to cPanel and look in the Metrics section.
2. Click Errors to see the most recent entries recorded for your account.
3. Each line shows the date, the error type, the file, and the line number – read from the bottom up, as the newest errors are last.

You can also find an error_log file inside the folder where the problem happened – for a main site, that’s usually public_html. Open it with File Manager or over FTP to read the full detail.

Reading what an error tells you

Most entries name the problem, the file, and the line – for example “PHP Fatal error: Uncaught Error… in /home/user/public_html/wp-content/plugins/example/file.php on line 42”. The file path usually points straight at the culprit: a specific plugin, theme, or custom script. A fatal error stops the page entirely, while a warning or notice lets it keep loading but signals code that may break on a newer PHP version.

Show errors while testing

If you’re actively debugging and want errors on screen, you can turn display_errors on temporarily under Select PHP Version → Options (see changing PHP settings). On WordPress, the cleaner route is to set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php, which writes everything to wp-content/debug.log without exposing it to visitors. Whichever you use, switch it back off the moment you’re finished.

First things to try

• “Memory exhausted” – raise memory_limit in PHP settings.
• “Maximum execution time exceeded” – raise max_execution_time for long tasks.
• “Call to undefined function” – a required PHP extension is switched off.
• Error points to one plugin – deactivate it to confirm, then update or replace it.

Need more help?

Found the error but not sure how to fix it? Open a ticket through Client Area → Support Tickets with the log line and our team will help you resolve it.