WP_DEBUG log grows without rotation obscuring recent deployment errors

Managing the WP_DEBUG Log

WordPress does not include internal log rotation. When WP_DEBUG_LOG is enabled, PHP appends all notices, warnings, and errors to wp-content/debug.log indefinitely. As this file grows, standard text editors and browser-based file managers often fail to load the end of the file, hiding the most recent stack traces generated during a deployment.

Immediate Resolution: Capturing Recent Errors

To see recent deployment errors without loading a massive file, use the tail command via SSH. This reads only the end of the file, bypassing the historical data that obscures current issues:

tail -n 100 wp-content/debug.log

Long-Term Strategy: Size-Based Rotation with logrotate

The most reliable way to handle debug.log without interfering with WordPress's file handles is using the Linux logrotate utility. Because WordPress opens the file in append mode, logrotate can move the file and create a new one without requiring a PHP restart.

Create a configuration file (e.g., /etc/logrotate.d/wordpress) with the following parameters:

/var/www/html/wp-content/debug.log {
    size 10M
    rotate 5
    missingok
    notifempty
    compress
    create 0664 www-data www-data
}

Implementation Details and Safeguards

• Permissions: The create directive ensures the new log file maintains the ownership (e.g., www-data) and permissions required for the web server to write to it.
• Rotation Method: Using size instead of daily/weekly intervals ensures rotation happens based on disk impact rather than time, which is critical during high-verbosity deployment phases.
• Security: Ensure debug.log is not publicly accessible. If your server does not block .log files by default, add a rule to your .htaccess or Nginx config to deny access to the file.

Verification Steps

1. Check wp-config.php to confirm the exact path of WP_DEBUG_LOG.
2. Manually trigger a rotation to test the config: logrotate -f /etc/logrotate.d/wordpress.
3. Trigger a known PHP notice (e.g., accessing a non-existent array key in a template) and verify the new debug.log captures the entry.

Missing Diagnostic Detail: Is WP_DEBUG_LOG set to true (defaulting to wp-content/debug.log) or a custom absolute file path? If a custom path is used, the logrotate path must be updated accordingly.