How to Create and Access Error Logs for WordPress (3 Methods)

WordPress error logs are diagnostic records that capture PHP errors, fatal exceptions, database failures, plugin conflicts, and theme incompatibilities as they occur on your server. Accessing and interpreting these logs is the fastest way to identify the root cause of a broken page, a white screen of death, or a silent performance regression — without guessing or disabling plugins one by one.

This guide covers three production-tested methods for enabling, locating, and reading WordPress error logs: the native WP_DEBUG stack, server-level logs via your hosting control panel, and plugin-based log viewers. Each method suits a different access level and use case, and all three are explained with exact file paths, configuration syntax, and security considerations.

Why WordPress Error Logs Matter

WordPress runs on PHP, which generates several classes of runtime messages: fatal errors (execution stops), warnings (execution continues but something is wrong), notices (informational, often indicating deprecated code), and deprecated messages (functions scheduled for removal). By default, none of these are written to a persistent log on most production configurations — they are either suppressed or echoed to the browser, which is a security risk.

Without a log, a plugin update that introduces a fatal error produces only a blank screen. A misconfigured SMTP library silently drops emails. A memory limit breach kills a page load with no visible trace. Error logs convert these invisible failures into timestamped, file-referenced, line-numbered entries you can act on immediately.

Method 1: Enable WordPress Debug Mode via wp-config.php

WordPress ships with a built-in debugging subsystem controlled by a set of PHP constants defined in wp-config.php. This is the most precise method because it captures WordPress-specific errors, including those thrown by the plugin API, the theme loader, and the database abstraction layer (wpdb).

Step 1: Locate and Open wp-config.php

Connect to your server via SFTP (preferred over plain FTP for security) using a client like FileZilla or Cyberduck, or open your hosting provider's File Manager. Navigate to the WordPress root directory, typically /public_html/ or /var/www/html/. The wp-config.php file sits at the root of this directory.

If you have SSH access, you can edit it directly:

nano /var/www/html/wp-config.php

Step 2: Configure the Debug Constants

Locate the existing line:

define( 'WP_DEBUG', false );

Replace the entire block with the following configuration, which enables logging without exposing errors to site visitors:

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

What each constant does:

• WP_DEBUG — activates the WordPress debugging engine and enables PHP error reporting at the E_ALL level.
• WP_DEBUG_LOG — writes all captured errors to a log file instead of (or in addition to) the screen.
• WP_DEBUG_DISPLAY — when set to false, suppresses on-screen output. This is critical on production sites; without it, PHP notices leak internal file paths and variable names to visitors.
• display_errors — the underlying PHP directive; setting it to 0 via ini_set provides a second layer of suppression in case a plugin or theme overrides WP_DEBUG_DISPLAY.

Step 3: Locate the Debug Log File

With WP_DEBUG_LOG set to true, WordPress writes errors to:

/wp-content/debug.log

This file is created automatically on the first logged error. You can view it over SFTP or SSH:

tail -f /var/www/html/wp-content/debug.log

The tail -f flag streams new entries in real time, which is invaluable when reproducing a specific error interactively.

Step 4: Use a Custom Log Path (Recommended for Security)

The default debug.log path is publicly accessible if your web server does not block it explicitly. A misconfigured server will serve https://yourdomain.com/wp-content/debug.log to any visitor, exposing internal paths, database table prefixes, and class names.

Option A — Move the log file outside the web root:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Create the target directory and set permissions:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Option B — Block the default path via .htaccess (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Option C — Nginx equivalent in your server block:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Step 5: Disable Debug Mode After Troubleshooting

Never leave WP_DEBUG set to true on a live site longer than necessary. Once the issue is resolved:

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

Leaving debug mode active on a production site degrades performance (PHP processes every E_ALL notice) and can expose sensitive stack traces if WP_DEBUG_DISPLAY is accidentally set to true.

Method 2: Access Server-Level Error Logs via Your Hosting Control Panel

WordPress errors that occur before the WordPress bootstrap completes — such as a corrupted wp-config.php, a PHP version incompatibility, or a failed database connection — will never appear in debug.log because WordPress itself never loads. For these, you need the server's PHP error log or Apache/Nginx error log.

cPanel-Based Hosting

If your hosting environment uses VPS with cPanel, the error log is accessible through the control panel interface:

1. Log in to cPanel.
2. Navigate to Metrics > Errors.
3. The panel displays the last 300 lines of the Apache error log for your account.

For the full log file, use cPanel's File Manager or connect via SFTP and navigate to:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

The exact filenames vary by server configuration, but the pattern is consistent across most cPanel installations.

Plesk-Based Hosting

In Plesk, navigate to Websites & Domains > select your domain > Logs. You can filter by log type (access, error, PHP) and download the full log file.

Direct Server Access (VPS or Dedicated)

On a VPS Hosting or Dedicated Server environment where you have root access, log locations depend on your stack:

To monitor the PHP-FPM log in real time:

tail -f /var/log/php8.2-fpm.log

To search for WordPress-specific fatal errors across the Apache log:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Configuring PHP Error Logging at the Server Level

If PHP errors are not being written to a log, check your php.ini configuration:

php --ini | grep "Loaded Configuration"

Open the identified php.ini file and verify or set:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Restart PHP-FPM after changes:

systemctl restart php8.2-fpm

Alternatively, override PHP settings per-site using a .htaccess file (Apache only):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Method 3: Use a WordPress Error Logging Plugin

For environments where direct server access is restricted — such as Shared Web Hosting — or for teams where non-technical administrators need to review errors without SSH access, a WordPress plugin provides a viable alternative.

Recommended Plugins

• WP Log Viewer — reads the existing debug.log file and displays it in the WordPress admin with filtering and search.
• Error Log Monitor — adds a dashboard widget showing recent errors and can send email alerts when new errors are logged.
• Query Monitor — goes beyond error logging to profile database queries, HTTP API calls, hooks, and conditional tags. Essential for performance debugging.
• Health Check & Troubleshooting — WordPress.org's official plugin; enables a troubleshooting mode that activates a default theme and disables all plugins for your session only, without affecting other visitors.

Installing and Configuring Error Log Monitor

1. In the WordPress admin, go to Plugins > Add New.
2. Search for Error Log Monitor and click Install Now, then Activate.
3. Navigate to Settings > Error Log Monitor.
4. Set the log file path. If you have moved debug.log outside the web root, enter the absolute server path here.
5. Configure email alert frequency if you want notifications for new error types.

The plugin reads the same debug.log file that WP_DEBUG_LOG writes to. It does not create a separate logging mechanism — it is a viewer. This means WP_DEBUG and WP_DEBUG_LOG must still be enabled in wp-config.php for the plugin to display anything.

Critical limitation: Plugins load after WordPress bootstraps. Any error that prevents WordPress from loading (database connection failure, corrupted core file, incompatible PHP version) will not be visible in any plugin-based log viewer. For those scenarios, Method 2 is the only option.

Comparison: Three WordPress Error Logging Methods

Reading and Interpreting WordPress Error Log Entries

A raw debug.log entry looks like this:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

How to read this:

• The timestamp is in UTC — convert to your server's local timezone if needed.
• PHP Fatal error means execution halted. The page that triggered this returned a 500 error or a blank screen.
• Call to undefined function get_field() means the Advanced Custom Fields plugin is either deactivated or loaded after the theme's functions.php tried to call it.
• The stack trace shows the exact file and line number. Start debugging at line 47 of functions.php.

Common error patterns and their causes:

• PHP Warning: require(): Failed opening required — a file path is wrong or a file is missing. Often caused by a plugin referencing a file that was deleted.
• PHP Deprecated: Function _register_controls is deprecated — a plugin or theme uses an outdated API. Not fatal, but indicates a plugin that has not been updated for the current WordPress/Elementor version.
• WordPress database error ... for query — a wpdb query failed. Check for table prefix mismatches or corrupted tables.
• Maximum execution time of 30 seconds exceeded — a script ran too long. Common with large imports, unoptimized queries, or external API calls that time out.
• Allowed memory size of X bytes exhausted — PHP hit the memory limit. Increase memory_limit in php.ini or identify the memory-leaking plugin.

Best Practices for Managing WordPress Error Logs

Rotate logs to prevent disk exhaustion. A busy WordPress site under attack or with a recurring error can generate hundreds of megabytes of log data per day. On Linux servers, configure logrotate:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Never commit debug.log to version control. Add it to .gitignore:

wp-content/debug.log

Audit your wp-config.php after every server migration. Hosting migrations frequently reset WP_DEBUG to false or introduce a new wp-config.php template that overwrites your constants.

Use SAVEQUERIES for database-level debugging. Add this constant alongside WP_DEBUG to log every SQL query WordPress executes:

define( 'SAVEQUERIES', true );

Then inspect $wpdb->queries in a custom template or via Query Monitor. Disable it immediately after use — it stores every query in memory and significantly increases RAM consumption.

Correlate log timestamps with deployment events. If a new error type appears, check whether it coincides with a plugin update, a WordPress core update, or a PHP version change on the server. Most hosting control panels log PHP version changes in a separate audit trail.

Decision Matrix: Which Method to Use

Technical Key-Takeaway Checklist

• Set WP_DEBUG_DISPLAY to false before enabling WP_DEBUG_LOG on any site with live traffic.
• Move debug.log outside the web root or block it via server rules — the default path is publicly accessible.
• Use tail -f on the log file when reproducing errors interactively; it eliminates the need to refresh the file manually.
• Server-level PHP and Apache/Nginx logs are the only source of truth for errors that occur before WordPress loads.
• Plugin-based log viewers require WP_DEBUG_LOG to be active — they are readers, not writers.
• Implement log rotation on any server where WP_DEBUG_LOG is enabled for more than a few hours.
• Never leave SAVEQUERIES enabled in production; it is a memory and performance liability.
• After resolving an issue, set all debug constants back to false and verify with a browser request that no PHP notices appear in the page source.

—

Frequently Asked Questions

Where is the WordPress debug log file located by default?

WordPress writes the debug log to /wp-content/debug.log relative to your WordPress root directory. This path is only created after the first error is logged and only when both WP_DEBUG and WP_DEBUG_LOG are set to true in wp-config.php. You can override the path by passing an absolute file path string as the value of WP_DEBUG_LOG instead of true.

Is it safe to enable WP_DEBUG on a live production site?

It is safe only if WP_DEBUG_DISPLAY is explicitly set to false and display_errors is set to 0. Without these two settings, PHP errors — including internal file paths and database table names — are rendered directly in the HTML source of every page. Always pair WP_DEBUG true with WP_DEBUG_DISPLAY false on any site with public traffic.

Why is my debug.log file empty even though WP_DEBUG is enabled?

The most common causes are: the web server process does not have write permission to the /wp-content/ directory; WP_DEBUG_LOG is set to false or is missing from wp-config.php; or the error is occurring at the server level before WordPress loads, meaning it will appear in the Apache or PHP-FPM log rather than debug.log. Check directory permissions with ls -la wp-content/ and verify the constants are defined in the correct order in wp-config.php.

What is the difference between WP_DEBUG_LOG and the server's PHP error log?

WP_DEBUG_LOG is a WordPress-level constant that routes errors captured by WordPress's custom error handler to debug.log. The server's PHP error log (configured via error_log in php.ini) captures all PHP errors at the interpreter level, including those that occur before WordPress initializes. On a properly configured server, both logs are active simultaneously and complement each other.

Can I enable error logging on shared hosting without SSH access?

Yes. You can edit wp-config.php via your hosting provider's File Manager in cPanel or Plesk, enable WP_DEBUG and WP_DEBUG_LOG, and then read debug.log through the same File Manager interface. For server-level logs on Shared Web Hosting, use the Errors section under Metrics in cPanel. If you need more granular control over PHP configuration and log paths, upgrading to a VPS Hosting plan gives you direct access to php.ini and full SSH access to all log files.