The Ultimate Guide to Finding Your WordPress Error Log

Why Knowing Where WordPress Logs Errors Can Save Your Website

Where does WordPress log errors is one of the most important things to know when your site breaks. Imagine waking up to a blank white screen, a “Critical Error” message, or an endless loading spinner. Without logs, troubleshooting turns into guesswork: you deactivate plugins at random, switch themes, or revert updates without knowing what actually failed. A log is your evidence trail. It tells you what happened, where it happened, and when. In the world of web development, flying blind is the fastest way to turn a minor glitch into a catastrophic outage.

WordPress is a complex ecosystem built on PHP and MySQL. Because it is designed to be user-friendly, it intentionally hides many technical messages from visitors. This is a deliberate design choice for both branding and security. Raw PHP errors can reveal sensitive server paths, database table names, and implementation details that a malicious actor could exploit. However, the downside of this “silent failure” approach is that when something goes wrong, the site owner is often left with no information. This is why understanding the logging mechanism is vital for anyone managing a WordPress site, from hobbyist bloggers to enterprise developers.

In most WordPress sites, errors are logged to debug.log in /wp-content/ after you enable debugging in wp-config.php.

Here are the most common log locations you will encounter in a standard environment:

A key detail to remember: WordPress does not always create debug.log automatically. The file is typically created only after logging is enabled and an actual error occurs. When it is working, each line usually includes a timestamp, the error type (Fatal error, Warning, Notice, Deprecated), and the file and line number involved. This level of granularity is often enough to pinpoint whether the issue is a plugin update that introduced a fatal error, a theme function calling a missing PHP function, a memory exhaustion problem, or a server-level permissions change that prevents file writes.

I am Kevin Gallagher, founder of wpOncall. After 15+ years managing WordPress websites and more than 2,500 sites built, I can tell you that logs are the fastest path from “my site is down” to a real fix. If you want a deeper overview of what gets logged and why, start here: wordpress-error-logs.

Know your where does wordpress log errors terms:

• debugging in wordpress
• wordpress debug
• debugging mode

Where Does WordPress Log Errors?

When people ask where does wordpress log errors, they usually mean: “Where can I see the PHP error that is breaking my site?” In WordPress, the most common answer is the debug.log file. But it is important to understand what WordPress does (and does not) log, as the application layer is only one part of the stack.

The WordPress application log: debug.log

When logging is enabled, WordPress writes PHP-related messages to a plain text file named debug.log inside your /wp-content/ directory. This directory is chosen because it is one of the few folders in a WordPress installation that is intended to be writable by the server for uploads and plugin data.

• Typical path on many hosts: /public_html/wp-content/debug.log or /var/www/html/wp-content/debug.log.
• What you will see: PHP fatal errors (which stop execution), warnings (which indicate potential issues but allow the site to load), notices (minor suggestions), and deprecated messages (notifying you of outdated code).
• What you may not see: Server configuration problems that happen before WordPress loads. For example, if your .htaccess file has a syntax error, the server will return a 500 error before it even tries to run the WordPress PHP files. In this case, debug.log will remain empty.

A common misunderstanding is that debug.log exists on every new install. It usually does not. WordPress avoids logging by default because writing to disk on every request can be unnecessary overhead on busy sites. Furthermore, if a site is under a heavy DDoS attack or experiencing a massive surge in traffic, an active log file can grow so quickly that it consumes all available disk space, leading to a secondary server failure.

Also note permissions: the /wp-content/ directory must be writable by the web server user (often www-data or apache) for WordPress to create and append to debug.log. If permissions are too restrictive (e.g., 555), you can enable logging correctly in your configuration and still never see the file appear. This is a common source of frustration for developers who think they have enabled debugging but see no output.

Server and PHP logs: when debug.log is not enough

WordPress runs on a server stack (web server + PHP + database). If WordPress never boots, debug.log might stay empty, and the answer to where does wordpress log errors shifts to server-side logs. These logs are managed by the operating system or the web server software itself.

Common examples where server logs matter:

• 500 Internal Server Error: Often caused by a misconfigured .htaccess rule or a server module issue. These are logged in the Apache or Nginx error logs.
• 502 Bad Gateway or 504 Gateway Timeout: Common on Nginx/PHP-FPM setups when the PHP process crashes or takes too long to respond. The error is logged in the Nginx error log and sometimes the PHP-FPM slow log.
• Syntax errors in wp-config.php: Since this file is the very first thing WordPress loads, a syntax error here (like a missing quote) can prevent the debugging constants from even being read. These errors will appear in the server’s PHP error log.
• File permission and ownership problems: If the server cannot read index.php, it cannot start WordPress. This is a server-level denial logged by the web server.

At wpOncall, we often check both WordPress logs and server logs to get a full picture. If you want the step-by-step to enable and locate logs on typical hosting, see: More info about error logging.

Where does WordPress log errors by default?

Once you enable WordPress debugging, the default location is wp-content/debug.log. However, it is worth noting that some managed WordPress hosts redirect these logs to their own proprietary logging systems. In those environments, the file might not exist in wp-content, but the data is accessible via the hosting provider’s dashboard.

Practical details that help during real troubleshooting:

• The file is generated only after an error occurs. If you just enabled logging and nothing has triggered an error yet, you may not see the file. Try refreshing the broken page to trigger the log entry.
• Timestamps are commonly recorded in UTC. WordPress defaults to Coordinated Universal Time for its logs to ensure consistency across servers in different regions. If you are matching an error to “what you just did,” remember to account for the UTC offset.
• It is a text file. You can open it with any editor, but large logs (over 100MB) are easier to search in tools like VS Code, Sublime Text, or Notepad++ rather than basic system editors like TextEdit or Notepad.

How to Enable WordPress Error Logging and Debug Mode

To get WordPress to start talking, you need to enable WP_DEBUG. This is a “constant” inside your wp-config.php file. Think of it like a master switch for the site’s diagnostic systems. When this constant is set to true, WordPress changes its behavior regarding how it handles PHP errors, allowing them to be captured or displayed.

By default, this switch is set to false on production sites to protect security and user experience. To turn it on, you will need to access your site’s root directory. This is usually the folder named public_html, www, httpdocs, or your site’s name. Inside, you will find wp-config.php, which is arguably the most important file in your entire installation because it connects your files to your database and contains your security keys.

Before you touch this file, we always recommend a full backup. A single missing semicolon or an accidental character in wp-config.php can take your entire site offline. At wpOncall, we handle these types of technical edits daily for our clients, ensuring that even a small syntax error in the config file doesn’t take the whole site down. If you want to dive deeper into the process, read our step-by-step guide to viewing logs.

Editing the wp-config.php File

Open your wp-config.php file using an FTP client or your hosting File Manager. Look for the line that says: define( 'WP_DEBUG', false );

Note: If this line does not exist, you should add it right above the line that says /* That's all, stop editing! Happy publishing. */. To answer the question of where does wordpress log errors and actually start seeing data, you should replace that single line with this comprehensive block of code:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings on the front-end
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Optional: Script Debugging for JS and CSS files
define( 'SCRIPT_DEBUG', true );

Why this specific code?

1. WP_DEBUG true: This is the core trigger. It tells WordPress to enter “debug mode.” Without this, the other constants will not function. It also enables the built-in WordPress error handler.
2. WPDEBUGLOG true: This is the magic line. It tells WordPress to send all errors to the debug.log file in wp-content. If you want to save the log to a custom location for better security, you can replace true with a specific file path, like '/home/user/logs/wp-errors.log'.
3. WPDEBUGDISPLAY false: This is a crucial security step. By default, if WP_DEBUG is true, WordPress might show errors directly on your website’s pages. You want the errors saved in a private log file, not splashed across your homepage for every visitor (and hacker) to see. This prevents “path leakage,” where an attacker can see your server’s internal folder structure. It also ensures your site’s layout doesn’t break due to error text appearing in the header or footer.
4. SCRIPT_DEBUG true: This is helpful if you suspect an issue with a plugin’s JavaScript or CSS. It forces WordPress to use the “unminified” versions of core files, making it easier to see where a script is failing in the browser console.

For more technical details on these constants, you can refer to the official WordPress Debugging mode documentation.

Using WP-CLI for Advanced Users

If you are comfortable with the command line, using WP-CLI is much faster than manually editing files via FTP. WP-CLI is a set of command-line tools for managing WordPress installations. This is particularly useful if you are managing multiple sites or if you have SSH access but no FTP access. It allows you to toggle debugging without ever opening a text editor.

To enable logging via SSH, navigate to your WordPress root directory and run these commands: wp config set WP_DEBUG true --raw wp config set WP_DEBUG_LOG true --raw wp config set WP_DEBUG_DISPLAY false --raw

This method is a favorite for developers because it is nearly instantaneous and avoids the risk of accidentally deleting a comma or semicolon in a text editor. It is part of the high-level toolkit we use at wpOncall to provide fast response times for our support clients. After running these commands, you can verify the settings by running wp config get WP_DEBUG. This ensures that the configuration is active and correctly formatted in the PHP file.

Methods to Access and View Your WordPress Error Logs

Once you have enabled logging, you need a way to actually look at the file. There are three main ways to do this: FTP/SFTP, your hosting Control Panel, or a dedicated plugin. Each has its pros and cons, but FTP is generally the most reliable if your site is currently “broken” and you cannot log into the WordPress dashboard.

Using FTP and SFTP Clients

FTP (File Transfer Protocol) and its more secure cousin, SFTP (Secure File Transfer Protocol), allow you to “log into” your server’s file system as if it were a folder on your own computer. You will need an FTP client like FileZilla or SmartFTP.

1. Connect: Enter your hostname (often your domain name or IP address), username, password, and port (usually 21 for FTP or 22 for SFTP). If you do not have these credentials, you can create them in your hosting dashboard under the “FTP Accounts” or “SSH Access” section.
2. Navigate: Once connected, you will see two panes. The left is your computer, and the right is your server. Go to the root folder (often public_html, www, or web) and then enter the wp-content folder.
3. Find the Log: Look for a file named debug.log. If you just enabled debugging, you may need to refresh the folder view to see it. If the file is not there, ensure you have triggered an error by visiting the site.
4. View: Right-click the file and select “View/Edit.” We recommend using a high-quality text editor like Sublime Text or Notepad++ because they handle large log files much better than the default Windows Notepad and provide syntax highlighting, which makes reading the logs significantly easier.

Accessing Logs via cPanel File Manager

If you don’t want to install software like FileZilla, most hosts provide a web-based File Manager inside cPanel or their custom dashboard. This is often the most convenient method for quick checks.

• Log in to your hosting account and find the Files section.
• Click on File Manager.
• Navigate to public_html/wp-content/.
• Highlight debug.log and click the View or Edit button in the top toolbar.
• If the file is very large (several megabytes), some web-based file managers might struggle to open it or may time out. In that case, you should download the file to your computer to read it locally.

This is often the quickest way for a site owner to answer where does wordpress log errors without needing to manage FTP credentials or SSH keys. It is also a great way to check file permissions if the log file isn’t appearing as expected; you can see the “Permissions” column right next to the file name.

Viewing Logs via SSH (Tail Command)

For developers who want to see errors in real-time as they happen, the tail command via SSH is incredibly powerful. This is known as “live debugging.” Once logged in via terminal, you can run: tail -f wp-content/debug.log

This command will keep the file open and print new lines to your screen the exact moment they are written to the log. This is perfect for situations where you perform an action on the website (like clicking a “Submit” button) and want to immediately see the resulting error in your terminal window without constantly refreshing a text file. To stop the live feed, simply press Ctrl + C.

Interpreting Data and Troubleshooting Common Errors

Once you find the log, the next challenge is turning log lines into actions. A debug.log entry is usually structured so you can answer four questions immediately: When did it happen? What type of error was it? Which file triggered it? And what line of code was involved? Understanding this structure is the key to rapid recovery.

A typical line looks like this:

[22-Oct-2023 15:30:12 UTC] PHP Fatal error: Uncaught Error: Call to undefined function... in /home/user/public_html/wp-content/plugins/bad-plugin/index.php on line 45

That one line often tells you the fastest fix: the error came from a specific plugin file. Disabling that plugin (or rolling it back) is usually the first step. For more examples and repair workflows, see our fix-wordpress-errors-guide.

Identifying Fatal Errors and Warnings

Not all log entries mean your site is “broken.” PHP uses severity levels that matter when you prioritize your fixes. If you see thousands of “Notices,” your site is likely fine, but a single “Fatal Error” can take everything down.

1. Fatal Errors

   • Symptoms: White Screen of Death, “There has been a critical error” message, or admin locked out.
   • Common causes: Calling a function or class that does not exist, plugin/theme code incompatible with your PHP version, or memory limit exhaustion (often shown as “Allowed memory size of X bytes exhausted”).
   • Typical first steps: Disable the named plugin/theme (FTP/File Manager rename is fastest if wp-admin is inaccessible). If it is a memory issue, you may need to increase the limit in wp-config.php using define('WP_MEMORY_LIMIT', '256M');.

2. Parse Errors (Syntax Errors)

   • Symptoms: Site fails to load immediately after editing code.
   • Common causes: Missing semicolon, unmatched bracket, or accidental characters in functions.php or wp-config.php.
   • Fix: Revert the last change. If the log points to a file and line number, open that exact file and correct the syntax. PHP is very strict; even a single extra space before a <?php tag can sometimes cause issues.

3. Warnings

   • Symptoms: Site may still load, but features behave oddly or certain elements are missing.
   • Examples: Missing include file, undefined array keys, or failed API calls.
   • Fix: Update the plugin/theme, or contact the developer if it is a recurring warning. Warnings often indicate that code is expecting data that isn’t there.

4. Notices

   • Symptoms: Usually none on production sites (unless errors are displayed).
   • Examples: “Undefined variable” or “Trying to access array offset on value of type null”.
   • Action: Often safe to ignore short-term, but it can signal sloppy code that may break in future PHP versions. Developers use these to clean up their code during the build phase.

5. Deprecated

   • Meaning: Code uses functions or behaviors that are being phased out in newer versions of PHP or WordPress.
   • Action: Treat as an early warning. Update plugins/themes before a future update turns a deprecated warning into a fatal break. This is common when upgrading from PHP 7.4 to 8.1 or higher.

Using Debugging Plugins for Easier Viewing

If you can still access wp-admin, a debugging plugin can make troubleshooting faster by surfacing errors in-context (which page, which query, which hook). These tools provide a graphical interface for the data found in debug.log.

• Query Monitor: A developer-focused tool that shows PHP errors, database queries, hooks, HTTP requests, and performance data. It is especially helpful when the site is slow rather than completely down.
• Debug Bar: A lightweight option that collects debugging info in one place. Many features require WP_DEBUG to be enabled to show data.
• WP Log Viewer: Focused specifically on presenting debug.log in the dashboard with search and filtering capabilities. This is great if you don’t want to use FTP.

Tip: Even with plugins, keep WP_DEBUG_DISPLAY disabled on production sites so errors are logged privately rather than displayed to visitors. For more advanced PHP logging techniques, you can refer to the PHP error_log documentation.

Security Risks and Best Practices for Error Logging

While the debug.log file is a hero during troubleshooting, it can become a villain if left unattended. If a hacker finds your log file, they can see your server’s file paths, the names of your plugins, and even specific code vulnerabilities. This is known as “Information Disclosure” or “Path Leakage.” In some cases, if a plugin is poorly coded, the log might even contain sensitive data like API keys, database queries, or user metadata.

At wpOncall, we emphasize that debugging should never be left on permanently on a live production site. It is a diagnostic tool, not a permanent feature. For a comprehensive look at how to handle this safely, check out our wordpress-debug-complete-guide.

Disabling Debug Mode After Troubleshooting

Once you have identified the bad plugin or fixed the code, you must turn the lights off. Leaving debugging on can also lead to the debug.log file growing to a massive size (sometimes several gigabytes), which can exhaust your server’s disk space and crash your site. Go back into your wp-config.php and set the constants back to false:

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

This stops the server from writing to the file, saving disk space and reducing server load. It also ensures that if someone does find your debug.log file, the information inside is stale and less useful for an attack. On high-traffic sites, the performance gain from disabling logging can be measurable.

Protecting the debug.log File

If you must keep logging active for a few days to catch an intermittent bug that only happens once every 24 hours, you should protect the file from public eyes. You can do this by adding a rule to your .htaccess file (for Apache servers). This file is located in your site’s root directory and controls how the server handles requests:

<files "debug.log">
 Order Allow,Deny
 Deny from all

</files

For Nginx servers, you would add a block like this to your site configuration file (usually located in /etc/nginx/sites-available/):

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

This tells the server that even if someone knows the exact URL to your log file (e.g., yourdomain.com/wp-content/debug.log), they are not allowed to see it. Additionally, remember to delete the debug.log file entirely once your troubleshooting is complete. Simply setting the constant to false stops new entries, but the old file remains on the server until you manually delete it via FTP or File Manager.

Frequently Asked Questions

Why is my WordPress error log empty?

There are usually four reasons for this:

1. No errors have occurred: Your site might actually be running perfectly! If there are no PHP issues, WordPress has nothing to write to the log. Try visiting a page you know is broken to see if it populates.
2. Permissions: The server doesn’t have “permission” to create or write to the file in the wp-content folder. You may need to set the folder permissions to 755 or 775 via FTP or your File Manager. In some cases, the file itself needs to be created manually and set to 664.
3. Incorrect Config: Double-check that define( 'WP_DEBUG_LOG', true ); is spelled correctly in your wp-config.php. Also, ensure it is placed above the “stop editing” line. If it is placed too low in the file, it may be ignored because WordPress has already finished its initialization.
4. PHP Error Logging Disabled: In rare cases, your host might have disabled error logging at the server level (in the php.ini file). You may need to contact your host to enable log_errors or check if they use a custom log path.

Can I delete the debug.log file?

Yes! You can delete it at any time. If debugging is still enabled, WordPress will simply create a fresh, empty file the next time an error occurs. This is a great way to “clear the slate” so you aren’t scrolling through thousands of old lines of text. It is actually a best practice to clear the log before you start a new troubleshooting session so you can be sure you are looking at current data. To learn more about managing these files, see can-i-delete-error_log-wordpress.

How do I find errors if I cannot access my dashboard?

If the “Critical Error” message is preventing you from logging in, you must use FTP or your hosting File Manager. This is why learning where does wordpress log errors is so vital—it is your only window into the site when the front door is locked. You can also check your server’s raw error logs in cPanel under the “Metrics” or “Errors” section. These logs often contain information about server-level crashes that the WordPress debug.log might miss, such as memory limits being hit at the OS level.

Does enabling debug mode slow down my website?

Yes, slightly. When WP_DEBUG is enabled, the server has to perform extra work to capture and write error data to the disk. On a small site with low traffic, you won’t notice the difference. However, on a high-traffic site, the constant disk I/O (input/output) can lead to slower page load times and increased server load. This is another reason why you should only enable it during active troubleshooting and never leave it on indefinitely.

What is the difference between debug.log and error_log?

You might see a file named error_log (without the debug prefix) in various folders like wp-admin or your root directory. This is a server-generated log created by PHP itself, rather than WordPress. While it contains similar information, it is often less organized than the WordPress debug.log. If you find both, the debug.log in wp-content is usually the more helpful one for WordPress-specific issues because it follows the WordPress-specific debugging constants.

Conclusion

Understanding where does wordpress log errors is the difference between being a frustrated website owner and a confident one. By using the debug.log file in the wp-content folder, you can unmask the hidden issues that slow down your site, cause plugin conflicts, or result in the dreaded White Screen of Death. It turns a guessing game into a precise science, allowing you to fix problems in minutes rather than hours.

However, we know that editing core files, managing FTP permissions, and navigating server directories isn’t for everyone. It requires a level of technical comfort and time that many business owners simply don’t have. A single mistake in wp-config.php can be more damaging than the error you were trying to fix in the first place. That is where we come in. At wpOncall, we specialize in WordPress security, maintenance, and expert support. Our team, based right here in Santa Rosa, CA, provides fast response times, daily updates, and unlimited support to ensure your website remains protected and optimized.

If you’re tired of chasing errors, worried about security vulnerabilities, or just want the peace of mind that comes with professional management, Get a professional WordPress Security Audit today. We will find the errors before they find you, keeping your business online and your data safe. Let us handle the logs while you handle your business.