WordPress debug.log on production, carefully

You can run WordPress debug logging on a live site if you write errors to a file and never show them in the browser. Set WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false in wp-config.php, then read and truncate the log after you capture the stack traces you need. Keep the log out of public reach, because traces often include paths and credentials.

Set the three constants correctly

WP_DEBUG turns debugging on. WP_DEBUG_LOG writes those messages to wp-content/debug.log unless you choose another path. WP_DEBUG_DISPLAY must stay false on production so visitors never see PHP errors in the page HTML.

Open wp-config.php above the line that says stop editing, and add or adjust these lines:

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

If you plan to leave logging on for several days, point the log outside the web root with ini_set( 'error_log', ... ) in the same file. That keeps the file away from public_html entirely.

Read the log, then keep it small

After you reproduce the problem, open the log from File Manager or SSH and pull the recent lines. Fatals usually match a white screen. Warnings that fire on every request are what fill the disk.

tail -n 30 ~/public_html/wp-content/debug.log

Copy the stack trace you need, fix or replace the plugin or theme that caused it, then truncate the file. A multi-gigabyte debug.log hurts backups and account quota. On WordPress accounts you can also use WP Toolkit to review plugins and push a fix from staging instead of leaving production logging on forever.

Deny web access to debug.log

By default, debug.log under wp-content may be reachable over HTTPS if nothing blocks it. Deny public access with a LiteSpeed or Apache rule, or move the log above public_html so the URL cannot serve it.

A plugin that writes passwords into the log is one you should remove, not one you protect with a weaker file mode. Rotate daily in File Manager or with a simple cron move if you truly need a week of history.

Turn debugging off when the incident ends

When the site is stable again, set WP_DEBUG back to false so harmless notices do not refill the file overnight. A short, deliberate logging window is useful. A permanent production log you never read only adds noise and risk.

Read the errors, fix the cause, truncate and deny the file, then decide whether logging stays on. Display should never stay on for a live site.