How a Text File Quietly Fills a Disk
With WP_DEBUG_LOG on, every PHP notice, warning and deprecation gets appended to
wp-content/debug.log. No rotation, no cap, no cleanup - it only grows. On a site
nobody watches, that file outlives the problem it was turned on to debug.
Everything was fine, then nothing works. Uploads fail. Updates fail. Sometimes
the site itself goes down. You check the disk: full. The single biggest file on it:
debug.log.
One plugin writing a notice on every request adds thousands of near-identical lines a day. Months later the log is gigabytes, backups bloat with it, and the first sign anything is wrong is a full disk - which looks like a hosting problem, not a logging one.
Why It Never Stops on Its Own
- The file is append-only. Nothing in WordPress rotates, truncates, or caps it - ever.
- The same notice repeats on every request. One deprecated function call on a busy page is a line per visit.
- On most sites WP_DEBUG should have been off on production months ago - the log keeps filling whether anyone reads it or not.
- And the bigger it gets, the less anyone opens it, so the real errors inside stay unread too.
What Debug Log Guard Does With It
Debug Log Guard finds the log PHP is actually writing - it honours the WP_DEBUG
constants and falls back to php.ini's error_log when that is the real target -
then gives you three things:
- A grouped summary. The same message collapsed into one row with a count, the source (core, plugin, or theme), and first/last seen. The line that filled two gigabytes sits at the top instead of repeating across four million rows.
- A live tail. The last 200 lines, streamed - it never loads the file into memory, so a multi-GB log opens in seconds instead of hanging the page.
- Safe shrink actions. Compact collapses the repeats, Rotate archives the file and starts fresh, Clear empties it. All three run backup-first and atomic - a partial write never corrupts the log.
The Hourly Size Guard
A WP-Cron job checks the log once an hour. Past your threshold - 50 MB by default - it runs the action you picked: compact, rotate, or clear, keeping the number of backups you set. You decide what "too big" means; the guard enforces it while you sleep.
It also knows when not to compact: a log already past ~1 GB gets force-rotated, because collapsing a multi-GB file is not a safe in-place operation. Compaction checks free disk first, scans giant files from the tail instead of the top, and runs on a time budget - if it runs out it aborts and leaves the original intact.
It runs on WP-Cron, so between ticks the file can still grow - the guard caps the damage, it does not stop the writes.
The Log Is the Symptom - Fix the Source
Shrinking the file does not fix whatever is writing to it. The grouped summary is the part that matters for that: the source column names the plugin, theme, or core file generating each message, so you can fix, replace, or report the thing spamming the log instead of deleting the evidence.
Two more warnings worth having. The Guard flags when WP_DEBUG_DISPLAY is left on in production - that prints errors to your visitors - and it warns when the log file itself is publicly reachable, which is a real thing people search for. If nobody reads the log on a live site, the honest fix is turning WP_DEBUG off; Config Manager writes the wp-config constants safely, with a backup.
Debug Log Guard is a Pro module - one click to a grouped table with the culprit named, and a cron guard that keeps the file capped.
Pro starts at $79/year →debug.log Too Large FAQ
Why is my debug.log file so big?
WP_DEBUG_LOG appends every notice, warning and deprecation - and the same message usually repeats on every request. One plugin writing a notice per page view is thousands of lines a day. Nothing in WordPress rotates or caps the file, so it grows until the disk is full.
Is it safe to delete debug.log?
Yes - it regenerates on the next error. But you lose the evidence of which plugin is spamming it, and if the cause is still there it fills right back up. Debug Log Guard's clear and rotate run backup-first, so you can shrink it without losing the data.
How do I stop debug.log from growing?
Two ways, and they are not the same job. Debug Log Guard's hourly size guard caps the file at your threshold - 50MB by default - with compact, rotate, or clear. Stopping the writes means fixing the plugin that spams them or turning WP_DEBUG off; the grouped summary names the source either way.
Does Debug Log Guard fix the errors in the log?
No - it shows you which plugin, theme, or core file is writing them. The grouped table gives each message a count and a source, so you fix or replace the culprit instead of repeatedly deleting a log that keeps refilling.
What if I need WP_DEBUG on a live site?
Then the safe setup is WP_DEBUG_LOG on, WP_DEBUG_DISPLAY off - and Debug Log Guard watching the size. It also warns when the log is publicly reachable, so the file you are keeping does not leak your paths to anyone who asks for it.
Will the size guard still run if WP-Cron is broken?
No - the hourly check rides WP-Cron, so if cron is not firing the guard cannot tick either. The manual actions and the grouped summary do not depend on cron and keep working regardless.
Shrink the Log, Keep the Evidence
Debug Log Guard groups the repeats, streams the tail, and compacts, rotates, or clears the file with a backup - then the hourly size guard keeps it capped. Pro module, $79/year for one site. Every paid plan includes all 19 modules.
Get Pro - from $79/year Site Down Guide All plans on the pricing page →