The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →The usual WordPress log is wp-content/debug.log. It is created only when WP_DEBUG is true and WP_DEBUG_LOG is enabled in wp-config.php. Keep WP_DEBUG_DISPLAY false so errors are recorded without being printed to visitors. If that file does not explain a failure, check your host’s PHP error log and web-server log as separate sources.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What WordPress logs contain
WordPress debugging routes PHP errors, warnings, notices, and messages sent with PHP’s error_log() function to a file. The default destination is /wp-content/debug.log, relative to your WordPress installation. The file is not guaranteed to exist on a new site: logging starts only after the relevant constants are enabled and a request generates an entry. WordPress documents this behavior in its debugging guide.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
Three different log systems are commonly confused:
| Log | What it can show | Typical location or access | Best use |
|---|---|---|---|
| WordPress/PHP debug log | PHP notices, warnings, fatal errors, and application messages generated while WordPress debugging is enabled. | wp-content/debug.log, or the custom path assigned to WP_DEBUG_LOG. |
Finding the plugin, theme, or WordPress file involved in an in-site error. |
| Host PHP error log | PHP failures that may occur before WordPress can write its own debug file, plus provider-specific runtime details. | Provider-specific dashboard, file, or download; the exact path is not stated by WordPress. | Investigating startup failures, memory problems, and requests that never reach normal WordPress execution. |
| Web-server log | HTTP requests, response codes, routing failures, and Apache- or Nginx-level errors. | Provider-specific dashboard or server path; the exact interface and path are not stated by WordPress. | Diagnosing 404, 403, 500, timeout, rewrite, and proxy-level problems. |
A single incident can appear in more than one source. Start with the WordPress file for an error inside the application, then move outward to PHP and web-server records when the file is empty or the request fails before WordPress loads.
How to turn on debug.log safely
Open wp-config.php in your site’s installation directory and add these definitions before the line that says That’s all, stop editing! Happy blogging.:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_LOG is a companion to WP_DEBUG; it has no effect unless WP_DEBUG is enabled. With the three settings above, WordPress writes diagnostic messages to the log while keeping warnings and notices out of the HTML response sent to visitors. The official configuration details are in the WordPress Developer Handbook.
Use a custom log path when the default is unsuitable
WP_DEBUG_LOG can be a valid file path instead of the Boolean value true. For example, a host may require logs outside the public document root. The path must be writable by the PHP process, and you must retrieve the file from that location rather than from wp-content. Keep the path private and use the host’s documented path syntax for your operating system.
Confirm that logging is active
- Save
wp-config.phpand make one request that reproduces the problem, such as loading the affected page or activating the suspected feature. - Open the configured destination. If the default is in use, look for
wp-content/debug.log. - Check the file’s modification time. A newly updated timestamp after the reproduction confirms that the request is writing there.
- If no file appears, verify that the constants are above the stop-editing line, that
WP_DEBUGis true, and that the PHP process can write to the destination.
Where to open wp-content/debug.log
You normally need access to the server filesystem. A hosting control-panel file manager, FTP/SFTP client, or SSH session can all work.
File-manager or SFTP procedure
- Sign in to your hosting account or connect with the SFTP credentials supplied by the host.
- Open the directory containing
wp-admin,wp-includes, andwp-content. This is the WordPress installation directory. - Open
wp-content, then selectdebug.log. - Use the file manager’s text viewer, or download the file and open it in a plain-text editor. Avoid editing entries while diagnosing; preserve the original copy.
- If
WP_DEBUG_LOGcontains a custom path, follow that path instead of looking inwp-content.
Reading it over SSH
After changing to the WordPress directory, a read-only inspection can be done with standard shell tools:
tail -n 100 wp-content/debug.log
tail -f wp-content/debug.logThe first command prints the most recent 100 lines. The second follows new entries while you reproduce an error; press Ctrl-C to stop watching. Use the custom path in both commands when one is configured. Download a copy before clearing or truncating a large file so that earlier evidence is not lost.
Finding logs on WordPress.com
WordPress.com provides a Site Logs view that records PHP errors and web-server requests. The exact controls depend on your WordPress.com plan and account interface; use the instructions in WordPress.com Site Logs documentation. Files created by a custom WP_DEBUG_LOG setting or by PHP’s error_log() are not necessarily shown in that dashboard. The documentation says to retrieve those files through SFTP or SSH.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
How to read a WordPress log entry
Read an entry from left to right rather than jumping straight to the final line. A useful first pass identifies four parts:
- Timestamp: establishes when the server recorded the event and lets you match it to a browser action, cron job, or deployment.
- Severity: labels such as Fatal error, Warning, and Notice indicate how urgently the event affected execution.
- Message: states what PHP or WordPress objected to, such as a missing function, an invalid argument, or an uncaught exception.
- File and line: identifies the PHP file and line where the event was reported. A stack trace may then show which plugin, theme, or core call led there.
Correlate the entry with a reproduction
- Make a backup copy of the current log, or note its last line number.
- Perform one controlled action that produces the symptom: load the failing URL, submit the form, or repeat the editor operation.
- Refresh the file and isolate entries written after that action.
- Compare the timestamp and request context with the failing feature. Repeated notices can be clues, but do not assume the most frequent line is the root cause.
If a stack trace names a plugin or theme file, check whether that component changed immediately before the failure. A path into WordPress core does not automatically mean core is defective; extensions often call core functions, and the trace shows the complete call chain needed to identify the initiating component.
Distinguish a warning from a fatal error
A notice or warning may allow the request to finish, although it can signal deprecated code or incorrect data that will become a future failure. A fatal error normally stops PHP execution and can produce a critical-error screen or an HTTP 500 response. Record the exact message, file, and line before changing code or disabling anything. Those details are what a developer needs to reproduce the fault.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When debug.log is empty or missing
The constants are not being loaded
Check that the definitions are in the active wp-config.php, above the stop-editing line, and that there is no later code redefining them. A staging copy and a production copy can have different configuration files, so verify the domain and filesystem you are actually testing.
The destination is not writable
For a custom path, confirm that the directory exists and that the PHP worker has permission to create or append the file. Your host may restrict writes outside approved directories; ask for the permitted location rather than granting broad permissions.
The failure occurs before WordPress logging starts
Bootstrap, PHP-extension, memory, or server-configuration failures can prevent WordPress from writing its own file. Check the host PHP log next. If the request returns a web-server error before PHP runs, inspect the web-server log as well.
The file is elsewhere
Search the installation for another debug.log only after checking WP_DEBUG_LOG. A custom path, a staging document root, or a managed-host dashboard can make the default location irrelevant.
Protect logs and turn debugging off after diagnosis
WordPress describes its debugging tools as development and staging aids. Verbose logging should not remain enabled indefinitely on a public site. After collecting the entries you need, set WP_DEBUG back to false and remove or disable the other debugging definitions unless your maintenance plan explicitly requires them.
Never expose debug.log at a predictable public URL. Entries can contain filesystem paths, usernames, database details, request data, and other implementation information. The wp-config.php handbook warns that publicly accessible logs are a security risk and recommends placing the file above the public root when possible. If that is not possible, restrict web access and file permissions through your host’s supported controls.
Quick Recap
Handle an existing public log
- Save a private copy for troubleshooting and incident review.
- Move it outside the web root, or apply the host’s access restriction mechanism.
- Remove sensitive historical entries when retention is no longer required.
- Disable verbose debugging and test the site again without displaying diagnostics.
A practical log-selection checklist
- Use
wp-content/debug.logwhen WordPress and PHP execute normally and debugging is enabled. - Use the configured custom path when
WP_DEBUG_LOGis a filename or absolute path rather thantrue. - Use the host PHP log for startup, memory, extension, or pre-WordPress failures.
- Use the web-server log for request routing, permission, rewrite, timeout, and HTTP-status problems.
- Reproduce one action at a time and match timestamps before editing code.
- Keep
WP_DEBUG_DISPLAYfalse during diagnosis on a live site. - Restrict or relocate log files and disable verbose debugging when the investigation ends.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
