WordPress Error Log Location: Where to Find It on Any Host

When something breaks on a WordPress site and you need to check the error log, the first question is always: where is it? The answer isn’t always the same. The default WordPress error log location is straightforward, but hosting environments, custom configurations, and security plugins can change it — sometimes without any obvious indication of where the file ended up.

This guide covers every place the WordPress error log can live, how to find it on different hosting environments, and how to access it without server navigation every time you need to check for errors.

The Default WordPress Error Log Location

When WP_DEBUG and WP_DEBUG_LOG are both set to true in wp-config.php, WordPress writes errors to:

/wp-content/debug.log

This path is relative to your WordPress installation root. On most shared hosting setups, the full server path looks something like /home/username/public_html/wp-content/debug.log, but the exact structure depends on your host’s directory layout.

The file is plain text and can be opened in any text editor. It doesn’t exist until the first error is logged after enabling WP_DEBUG — WordPress creates it on demand.

Custom WordPress Error Log Locations

The default path can be changed. When WP_DEBUG_LOG is set to a file path string instead of true, WordPress writes the log to that custom location:

define( 'WP_DEBUG_LOG', '/custom/path/to/my-debug.log' );

Some plugins and hosting environments do this automatically to store the log outside the web root (making it inaccessible via a public URL) or in a standardised location alongside other server logs. If you’ve enabled WP_DEBUG but can’t find the log at /wp-content/debug.log, a custom path is likely the reason.

WordPress Error Log Locations by Hosting Environment

Different hosting types handle WordPress debug logging differently:

• Shared hosting (cPanel) — Default path applies unless you’ve configured a custom one. The file manager in cPanel lets you navigate to /public_html/wp-content/ and open the file directly. Some cPanel setups also have a separate server-level error log under Metrics → Error Log, which is separate from the WordPress debug log.
• Managed WordPress hosting (Kinsta, WP Engine, Flywheel) — These platforms often manage debugging through their own dashboards rather than wp-config.php. Kinsta, for example, provides a WordPress error log viewer in their MyKinsta control panel. Check your host’s documentation rather than assuming the default path.
• VPS or dedicated server — Default path applies. You can also configure PHP’s own error_log directive in php.ini to write server-level PHP errors to a separate file, which is different from the WordPress debug log.
• Local development (Local by Flywheel, MAMP, Laragon) — These environments typically configure their own log paths. Local by Flywheel stores logs in the site’s logs/ directory in the app’s file structure rather than inside WordPress.

Finding Your Exact Log Path Without Guessing

Rather than navigating every possible location, Logmate’s System Info screen shows the exact file paths for both your PHP debug log and JavaScript log on your specific installation. Go to Logmate → System Info — the Debug Logs section lists the PHP log path and JS log path used by your site, along with the current file size of each. This eliminates the guesswork entirely regardless of your hosting environment or configuration.

Logmate also makes reading the log unnecessary from the server — once it knows the log path, it reads and displays the contents inside the WordPress admin, organised in a searchable table with PHP and JavaScript errors separated, sortable by occurrence count, and exportable when you need to share with a developer.

Securing the WordPress Error Log File

The default location at /wp-content/debug.log is within the web root, meaning it could potentially be accessed at yourdomain.com/wp-content/debug.log if not protected. Most WordPress configurations block direct file access to this path via .htaccess, but it’s worth verifying that the URL returns a 403 or 404 rather than the file contents.

To secure it explicitly, add this to your .htaccess file:

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

Alternatively, use a custom log path outside the web root by setting WP_DEBUG_LOG to an absolute path above your public_html directory. Logmate stores its own log files at randomised, non-guessable paths within the uploads directory for exactly this reason.

Frequently Asked Questions About WordPress Error Log Location

My debug.log file doesn’t exist. Why?

WordPress only creates the debug log file when the first error is written to it after enabling WP_DEBUG and WP_DEBUG_LOG. If both constants are active and no log file exists, either no errors have occurred since enabling debug mode, or the file is being written to a different path than you’re checking. Trigger a known error (loading a page with a broken plugin) to force the file to be created, then look for it.

Is there a server-level error log separate from the WordPress debug log?

Yes. Most hosting environments maintain their own PHP and server error logs separately from the WordPress debug log. These capture errors that occur before WordPress fully loads — useful for diagnosing white screens that happen at the server level before any WordPress code runs. Check your hosting control panel for an “Error Log” viewer, or ask your host where their server logs are kept.

Can I change the WordPress error log location without editing wp-config.php?

The WP_DEBUG_LOG constant in wp-config.php is the standard way to set a custom path. Some managed hosts offer this as a dashboard setting. Logmate abstracts the log location by finding and reading the file wherever it is — so even if the path changes, Logmate’s Logs screen continues to show the correct file.

---

The WordPress error log location varies more than most documentation suggests. The fastest way to find it on any site is Logmate’s System Info screen, which shows the exact path currently in use. From there, Logmate reads the file and presents it in the dashboard — so the location becomes irrelevant for day-to-day error monitoring.

You might also like:

• WordPress Debug Log: What It Is and How to Use It
• How to View WordPress Error Logs (Every Method Explained)
• How to Enable WordPress Debugging (The Safe Way for Live Sites)