How to Monitor WordPress PHP Error Logs on the Server

The fastest way to monitor WordPress PHP error logs on the server is to open an SSH session, run tail -f against the active log file, then reload the broken page and watch the errors appear in real time. Server-level logging catches problems that never reach WordPress, including memory exhaustion and syntax errors in a plugin file. A debug log inside wp-content is useful, but it is the second source of truth, not the first.

Most sites already write these logs. The issue is that almost nobody looks at them until something breaks, by which point the file may have rotated away.

Server Logs and the WordPress Debug Log Are Not the Same File

Two separate systems record PHP errors, and they capture different failures. Knowing which one to read saves an hour of guessing.

• The PHP error log on the server is written by PHP-FPM or Apache, based on the error_log directive in your PHP configuration. It records fatal errors, segmentation faults and out-of-memory kills, even when WordPress never finishes booting.
• The WordPress debug log (wp-content/debug.log) is written only after wp-config.php loads. It shows deprecated function calls, notices from themes and plugin warnings that the server log may suppress.
• Web server access and error logs (nginx or Apache) show 500 and 504 responses with timestamps you can match against the PHP entries.

If a page returns a blank white screen with no entry in debug.log, the failure happened earlier than WordPress, so go straight to the server log.

Where the PHP Error Log Actually Lives

Paths vary by stack, so check these locations in order before assuming logging is off:

• ~/public_html/error_log or ~/logs/error_log on most cPanel accounts
• /var/log/php-fpm/www-error.log or a per-pool log such as /var/log/php-fpm/yoursite-error.log
• /var/log/nginx/error.log and /var/log/apache2/error.log on self-managed servers
• /wp-content/debug.log once WP_DEBUG_LOG is switched on

Not sure which path PHP is using? Run php -i | grep error_log from the command line, or create a temporary file containing <?php phpinfo(); and read the error_log row. The PHP manual on error handling directives explains how log_errors, error_reporting and display_errors interact, which matters when a host sets them at the pool level. On a managed WordPress hosting plan with per-site PHP settings, the log path is usually listed in the dashboard next to the PHP version selector.

Turning On the WordPress Debug Log Without Exposing Your Site

Edit wp-config.php above the line that reads “That’s all, stop editing” and add the following block:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define( 'SCRIPT_DEBUG', true );

Setting WP_DEBUG to true turns reporting on, while WP_DEBUG_DISPLAY set to false keeps the errors out of the browser so visitors and bots never see file paths. You can also point the log somewhere outside the web root: define( 'WP_DEBUG_LOG', '/home/user/logs/wp-debug.log' );. Official guidance on these constants is documented in the WordPress debugging handbook.

Turn debugging off again once the issue is closed. A public debug.log hands attackers plugin versions and absolute paths, which is why it belongs in the same conversation as server-side and WordPress-side hardening rules.

We cover this topic in more depth in Composer in WordPress: Managing Dependencies on the Server.

For a closer look at this topic, see our guide: Resolving Memory Exhausted Errors (How to Increase PHP Memory Limit).

For a closer look at this topic, see our guide: How to Resolve the "502 Bad Gateway" Error in WordPress.

For a closer look at this topic, see our guide: Fixing the "Error Establishing a Database Connection" Fast.

Related reading: Managing Cron Jobs in WordPress: WP-Cron vs. Real Server Cron.

Reading a Log Entry Line by Line

A single PHP error line carries four useful pieces of information. Here is a typical one:

[12-Jan-2026 09:14:03 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_order() in /home/site/public_html/wp-content/plugins/orders-widget/render.php:88

• Timestamp in UTC, which you match against the request time in the access log
• Severity: Fatal error stops execution, Warning and Notice do not, Deprecated warns about a future break
• Message, usually naming the missing function, class or variable
• File and line number, which tells you the responsible plugin or theme in seconds

Fatal errors deserve immediate attention. Repeated deprecation notices matter too, because they predict what will break on your next PHP major version upgrade.

Watching Logs in Real Time Over SSH

Live tailing is the technique that separates a five minute fix from an afternoon of trial and error. Connect over SSH, then use these commands:

• tail -f wp-content/debug.log streams new lines as they are written
• tail -n 100 ~/logs/error_log prints the most recent 100 entries
• grep -i "fatal error" error_log | tail -20 filters out the noise
• grep -c "PHP Warning" error_log counts how often a warning repeats
• wp plugin deactivate slug via WP-CLI isolates a suspect plugin while you watch the stream

On macOS the same commands work in Terminal with no extra software, since the tools ship with the operating system. If you are still testing locally, the log paths differ under XAMPP or Local, and they change again after moving a localhost WordPress site to a live server, so re-check the path after every migration.

Checking Logs in cPanel Without the Command Line

cPanel users can open Metrics > Errors to see the last 300 entries the web server recorded, which is enough for most single-site troubleshooting. For older entries, use the File Manager or an SFTP client to download error_log from the site root and open it in a text editor. WooCommerce stores its own records separately under wp-content/uploads/wc-logs/, and those files often explain failed payments better than the PHP log does.

When the Debug Log File Never Appears

A missing debug.log usually comes down to one of five causes. Work through them in order:

1. The wp-content directory is not writable, so set it to 755 and confirm the PHP user owns it
2. WP_DEBUG is defined twice in wp-config.php, and the first definition wins
3. A security plugin or hosting rule disables file logging at the platform level
4. No errors have occurred yet, since the file is created on the first logged event
5. A custom WP_DEBUG_LOG path points at a directory that does not exist

Force a test entry with error_log( 'log test ' . date( 'c' ) ); inside a mu-plugin. If nothing is written anywhere, logging is disabled in the PHP configuration itself.

Keeping Log Files From Filling Your Disk

A noisy plugin can write a multi-gigabyte log in a weekend, and a full disk takes the whole site down. Configure logrotate with daily rotation and 14 days of retention, or truncate manually with truncate -s 0 error_log rather than deleting the file while PHP holds it open. Busy publishers and course platforms should also forward fatal errors to email or Slack, because nobody reads a log file on a quiet Sunday. Hosting built for business WordPress sites and online course platforms generally handles rotation and alerting at the platform level, which removes the disk risk entirely.

Frequently Asked Questions

Where Can I Find the WordPress Error Log File?

The WordPress error log sits at /wp-content/debug.log once you set WP_DEBUG_LOG to true in wp-config.php. Server-level PHP errors are recorded separately, most often in ~/public_html/error_log on cPanel hosts or /var/log/php-fpm/www-error.log on PHP-FPM stacks.

Does WordPress Have an Activity Log?

Core WordPress has no built-in activity log, so user logins, plugin activations and content edits are not recorded by default. Plugins such as WP Activity Log or Simple History add that tracking, typically retaining 30 to 90 days of events, and they complement rather than replace PHP error logging.

How Can I Check for Errors in PHP?

Run php -l filename.php to lint a single file for syntax errors, which takes under a second and needs no browser. For runtime problems, enable log_errors with error_reporting set to E_ALL, then reproduce the request while tailing the log.

Where Does the PHP error_log Go?

PHP writes to whatever path the error_log directive specifies in php.ini, and if that value is empty the messages go to the web server error log instead. Confirm the exact destination with php -i | grep error_log from the command line.

Get Server-Level Logging Set Up on Your Site

Our team configures PHP error logging, rotation and fatal-error alerts on every plan, so you see problems before your visitors do. Talk to a WordPress hosting specialist about your current log setup and what it is missing.