Your WordPress debug.log Can Quietly Eat the Whole Disk | WP Multitool

Skip to main content

Troubleshooting<br>Jun 22, 2026<br>5 min read<br>By Marcin Dudek

Your WordPress debug.log Can Quietly Eat the Whole Disk

I optimize WordPress sites for a living - retainers and one-off rescues. And there's one thing I find on client site after client site, usually while I'm hunting down why…

I optimize WordPress sites for a living - retainers and one-off rescues. And there's one thing I find on client site after client site, usually while I'm hunting down why the thing is slow: a wp-content/debug.log that's 5 GB. Sometimes more. Enabled months ago, never turned off, quietly growing a few hundred bytes at a time on every single request.

It's a strange file to feel two ways about. On one side it's a mine of information - every slow query, every deprecation, every PHP warning the site ever threw is in there. On the other side, sifting through 5 GB of crap to find the useful part takes ages, and half the time the disk is one bad day away from filling up because of it.

So a WordPress debug.log too large to even open is one of those failures that stays invisible right up until it takes the whole site down. And WordPress has no built-in way to cap that file, rotate it, or collapse the duplicates. It just keeps writing.

I built a module to deal with it: Debug Log Guard. It shipped in WP Multitool 1.5.0, and this is what it does and - just as important - what it doesn't.

Why this happens

When WP_DEBUG_LOG is truthy, WordPress points PHP's error log at wp-content/debug.log and PHP does the appending. That's it. There's no size limit, no dedup, no rotation. PHP wasn't designed to babysit the file - it just writes what you tell it to.

So a single noisy plugin firing E_DEPRECATED on every request is enough. The line is identical each time except for the timestamp. Most of that giant file is one error, copied a hundred thousand times over.

And here's the part that makes it worse: once the file is big, you can't even look at it. Open a 4 GB log in a text editor and you'll OOM your laptop. cat it on a 256 MB VPS and you might knock the box over. The tool you'd normally reach for to diagnose the problem becomes part of the problem.

What everyone actually does about it

Before I built this I asked around in r/WordPress - how do people deal with a debug.log that's eaten the disk? The answers were honest and they all fell into two camps.

Camp one: delete it. "Just disable WP_DEBUG and delete the file." "Force the site to error and let it produce fresh ones." That works, and I get why people do it. But you're throwing away the only record of what's been going wrong. If a bug only fires in some specific case, you've just signed up to reproduce it from scratch, and you won't know it's gone until it isn't.

Camp two: feed it to AI. "Paste it into Claude and ask for a summary." Good instinct - except a 5 GB file doesn't fit in any context window. So it collapses back into "just feed in today's slice," and you're back to guessing which slice matters.

The few people with a real answer reached for server tools - logrotate, or a cron that runs truncate weekly. That caps the size, but it's still lossy and it lives outside WordPress, so most site owners never set it up.

What none of these do is the hard part: read a multi-gigabyte file without falling over, and shrink it safely without losing the errors you need. That's the gap. Viewers that read the log and show distinct errors with a count already exist, some are free, and grouping-on-display is table stakes now - I'm not going to pretend that part is hard. The hard part nobody handles well is reading a multi-gigabyte file without falling over, and shrinking it safely without losing the errors you actually need. That's where I put the work.

What Debug Log Guard actually does

Three things.

It reads the log without loading it into memory. Everything streams in bounded chunks. The grouped summary, the tail view - none of it pulls the whole file into RAM. So a 4 GB log on a small box doesn't crash the very tool you're using to fix it. For a genuinely huge file it scans the most recent slice and tells you it's showing a partial view, instead of hanging.

It groups the repeats so you see the real culprit. It strips the timestamp, hashes what's left, and counts. Instead of scrolling through 200,000 identical lines, you get a table: the message, how many times it fired, which plugin or theme it came from, and when you first and last saw it. The worst offender sits at the top. At a glance you know whether you have one screaming plugin or twenty small leaks.

The grouped summary collapses hundreds of thousands of identical lines into one row, with the worst offender on top.<br>It compacts the file safely. This is the bit I care about most. Compact collapses every repeated line into one annotated entry - it keeps the message, replaces the 50,000 copies with a [compacted x50000] note, and preserves...