WordPress log not being created: find where errors are going

A missing file does not mean no failure exists

You enabled WordPress debugging, but no debug.log file appears, or the file remains empty during the error. This proves neither that WordPress works correctly nor that permissions must be the problem. The message may go to another destination, occur before logging is enabled, or not be a PHP error.

A log is not a record of every click. A successful action may write nothing, and an HTTP rejection produced by a proxy may never reach WordPress. The file may also have another name if its destination was customized. Searching only for wp-content/debug.log then becomes misleading.

The expected result is more precise than creating an empty file: you need to know which request reaches PHP, where its messages are sent, and how to find a relevant dated entry. We will check this chain without displaying errors to visitors. Once the message is obtained, repairing its cause belongs to the guide for that error, not another logging change.

Confirm the request, site, and file being inspected

Record the problematic address, time with time zone, and action performed. For a process that may send a payment or email, first use the failure already recorded. Replaying a sensitive operation to fill a log may create a second effect when the first attempt partially succeeded.

This guide assumes authorized access to installation files or hosting logs. On a managed platform, the destination may be a private screen or collector rather than a file accessible through SFTP. In a multisite network, code and some logs may be shared; identify the subsite without assuming it has its own file.

On WordPress.com, start with the diagnostic tools and access actually available for your site. If you cannot open its configuration, use private logs or support; WordPress dashboard access alone does not provide the ability to modify server files.

1. Record the URL and exact failure window, then confirm which domain and environment you are examining.
2. Identify the WordPress file root and active configuration in the hosting panel.
3. Check the path actually being inspected and the log’s modification date, if it exists.
4. Distinguish a test copy from production and a cached response from a new PHP execution.

Preserve configuration and private information

Before editing wp-config.php, keep a copy in a private location outside every web root in the account. This file usually contains secrets. A copy ending in .bak left beside the original may become downloadable depending on server configuration. Also keep file access open so you can undo a syntax error.

Prefer a protected working copy with outbound messages and payments disabled. Protection must actually cover that environment, not just its homepage. A file and database backup is useful before broader work; here, particularly preserve previous logging values and how to restore them.

The log may contain paths, addresses, query fragments, or personal data. Limit the collection period and who can access it. Hiding error display does not protect a file available by URL. If no private location accepted by PHP is available, use the host’s built-in log instead of leaving sensitive traces in a public directory.

Check constants before WordPress starts

In the active file, search for WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY. Enabling the WordPress log depends on debug mode. Do not confuse the setting enabling collection, the one choosing its destination, and the one allowing display in the page.

The example below uses an illustrative private path to replace with a confirmed location. The booleans true and false remain unquoted; the path is text and is quoted. Modify existing definitions instead of adding more. A repeated definition does not properly replace the first value.

1. Open the active configuration in a text editor and record initial values.
2. Place or correct these definitions before wp-settings.php loads and starts WordPress.
3. Replace the example path with the actual private absolute path provided for this site.
4. Save without adding a new PHP opening tag in the middle of the file, then check that the site still starts.
5. If a new error appears, restore the previous version through file access.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/chemin/prive/autorise/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Look for the correct destination rather than only debug.log

When WP_DEBUG_LOG is the boolean true, WordPress uses the content directory defined for the installation with the name debug.log. This directory may have moved. When the constant contains a path, inspect that destination. Configuration targeting a private log should not additionally create a public copy for easier reading.

The parent directory must already exist and be accessible to the site’s PHP process. Being able to upload a file over SFTP does not demonstrate that PHP can write there: the two operations may use different identities. If the file already exists under different ownership, a new entry may also be rejected.

In file access, display the exact private directory, then refresh its listing after the request. Check the name, size, and date without mistaking a downloaded copy’s date for the server file’s date. If hosting centralizes logs elsewhere, ask for its viewing screen and domain filter. The useful result is an identified destination, not several simultaneous logs whose active status nobody knows.

Verify a controlled entry only on a copy

On a private copy whose configuration you control, a neutral marker can distinguish the absence of an error from the absence of writing. This optional step suits a maintainer able to edit and restore the file. It is unnecessary if a recent error already appears in the log, and must not be added permanently to production.

In a conventional wp-config.php, temporarily place the line below in the PHP code immediately after the existing statement loading wp-settings.php, before any PHP closing tag. Do not duplicate that loading statement. The marker contains neither secrets nor visitor data. If your architecture ends the request before this point, its absence will not permit a conclusion.

The marker’s presence validates only this manual call and its destination for the observed request. It does not demonstrate that every error level is collected automatically. Nor should you rely on the return value of error_log(): with the default type used here, PHP may return true even if the message was not recorded. Check the line actually found.

1. Back up the copy’s file and verify that the private destination is ready.
2. Add only the marker line at the indicated location.
3. Load a page on the copy that actually executes WordPress, without a business operation.
4. Look for the marker at the expected destination and time, then immediately remove the line.
5. Its presence confirms this writing path for this request; its absence requires checking startup, cache, and destination without deliberately triggering a fatal error.

error_log( 'ATELIER-DIAG-JOURNAL' );

Consult the server log for an error occurring too early

A syntax error in configuration may prevent PHP from executing the lines meant to enable the WordPress log. Similarly, an engine failure, a service-imposed limit, or a web-server rejection may occur before that activation. Changing WP_DEBUG_LOG again cannot go back in time.

Open the PHP or domain error log provided in the hosting panel. Filter the exact domain and time window. The access log describes received requests; the error log describes certain failures. They are not interchangeable, but correlating them helps show whether the request reached the intended service.

If a recent error names wp-config.php or a file loaded before core, restore the last relevant change or have the maintainer make a targeted correction. Do not modify core files to start debugging earlier. The expected result here is a usable server entry even if no WordPress log is created. Its absence from debug.log is then consistent with the stage at which the failure occurred.

Compare the web and terminal contexts

A terminal command may use a different PHP, INI file, and user from the website. Writing a message from WP-CLI or observing that a directory is accessible to your account therefore does not, by itself, verify logging for a visitor request.

For the web context, use the host’s private information and, when administration works, Tools > Site Health > Info > Server. Record the PHP version and available context details, then have the provider confirm the effective error destination. Do not publish a phpinfo() page to compare settings.

PHP has its own log_errors and error_log parameters. The destination may be a file, service log, or system collector. Hosting configuration may also impose values preventing runtime changes. Ask which value actually applies to domain requests instead of adding several configuration calls in different files. If site and terminal differ, record both contexts and correct the one producing the failure.

Fix denied writing without opening all permissions

If the server log reports denied access, have the file owner, parent-directory permissions, and domain’s PHP identity checked. If the destination does not exist, the process must be able to create the file in that directory; if it exists, it must be able to append data. The same permission number does not guarantee those conditions on every host.

An open_basedir restriction may also exclude the chosen private path. It controls permitted paths and is not fixed by applying 777. Have an already-authorized private location used, or have its administrator precisely adjust the scope. Do not authorize the entire server tree for a single log.

Also check disk-space and file-count quotas when the service refuses to create new items. Preserve useful logs before any planned rotation, and do not randomly delete backups to free space. After a targeted fix, repeat a single check request and look for a new entry. If it appears, record the concrete cause identified and setting corrected; manually creating an empty file would not have demonstrated this result.

Have a setting overridden during loading identified

Initial configuration may be correct, then a component may change PHP logging parameters or install its own error handler. A custom environment may also adapt checks very early in startup. These are hypotheses to verify in loaded code, not reasons to disable every protection.

If the problem follows a specific change, compare that version with the previous one on the copy. Ask the maintainer to look for changes to the error_log destination, log_errors, or error handlers in the affected component. For an architecture customizing startup, also have the enable_wp_debug_mode_checks filter examined; it runs before ordinary plugins and must not be forced without understanding its role.

The test must isolate the confirmed component and preserve the copy’s intended operation. If a hosting policy deliberately centralizes traces, use its collector instead of adding a competing mechanism. Document where the decision is made and how to check it. A constant visible in a file does not necessarily describe every effective setting at the end of the request.

Observe page-load errors with Query Monitor

If administration still works, Query Monitor can complement investigation on a copy. This free plugin by John Blackbourn displays, among other things, PHP errors from the current page load. The verified version is 4.1.1, requiring at least WordPress 6.3 and PHP 7.4, with declared compatibility up to WordPress 7.1.4. These details do not constitute a test on your site.

Prefer an already-installed instance. Otherwise, on the authorized copy, open Plugins > Add New, search for Query Monitor, and verify the name and author before installing and activating. Do not add a second collection tool if an equivalent one already covers this need.

1. Log in with the maintenance account, then open the page reproducing the problem.
2. In the admin bar, open Query Monitor and its PHP Errors panel when it reports errors.
3. Record the indicated message, level, caller, and component, along with the page context.
4. Compare this record with the private log at the same time.
5. Deactivate the tool after investigation if installation was temporary. It does not repair disk writing, reconstruct past events, or guarantee capture of a failure occurring before it loads.

Validate the collection path before using the error

Once collection is recovered, verify that it describes the original problem. An unrelated old warning, a message from another domain, or a marker from the terminal is insufficient. Correlate time, request path, and named component. Keep a few contextual lines without exporting every user’s complete traces.

If only a check entry appears and not the failure, the check’s path works; the problem may occur elsewhere or emit no PHP error. Then examine the network response or relevant service log. Do not expand public display to obtain more information.

1. Confirm a new event appears at the identified destination.
2. Check that public error display remains disabled and storage is private.
3. Reproduce only an action with no external effect, or use the already-recorded business attempt.
4. Associate the useful entry with its context and send a redacted excerpt to the person responsible for repair.
5. Separate “collection operational” from “failure repaired”: the latter requires its own functional checks.

Remove temporary diagnostics and keep a usable procedure

Restore constants and server settings to the agreed state after collection. Do not remove permanent logging configuration imposed by hosting; remove only your temporary additions. Check differences before restoring an old complete file, because another legitimate intervention may have changed its configuration meanwhile.

Remove the marker from the copy and any diagnostic page created outside this procedure. Store the useful excerpt privately with its date and an appropriate retention period. If a log copy was publicly exposed, have its contents assessed instead of assuming that renaming it is enough to erase the exposure.

Then check the homepage, login, and initially affected action. Document the domain log, its destination, the relevant PHP context, and who can view it. The next failure will thus not require hurriedly recreating a collection mechanism. If no event could be obtained, report precisely the checked paths and contexts and the limitation encountered; do not claim there is no error solely because a file is empty.

Read the marker without confusing it with the failure

An illustrative line might look like [13-Nov-2026 09:15:00 UTC] ATELIER-DIAG-JOURNAL. The exact prefix depends on the logging system; only the marker is fixed by the guide’s snippet. This example is not a record of a test on your site.

If the line appears at the time of your new web request, the destination has been found for that call. Immediately remove the marker, then look for the original error in the same time window. If only the check line exists, the failure may be a normal REST response, proxy rejection, or event in another process; increasing log permissions will not necessarily provide information.

If the line does not appear, check in this order: did the request bypass the page cache; is the correct configuration file loaded; is this point in the file reached; does the service impose another destination; can PHP write there? A syntax error before core loading requires the server log. Query Monitor is useful for a still-inspectable response, but installing it does not recreate a past trace. Keep a short record with time, domain, request type, and confirmed destination without copying the entire log.