Magento does not rotate its own logs
Out of the box, Magento writes to files in var/log and never cleans them up. There is no built-in rotation, so those files grow until something else stops them, usually a full disk.
This is separate from database bloat. It lives on the filesystem, and it fails in a different, more sudden way. The disk fills, and the site goes down.
This article covers which files grow, why production debug logging is the worst offender, and how to set up rotation so a log file never takes the store offline.
Which files grow, and how fast
The core logs in var/log are system.log, debug.log, and exception.log. Extensions add their own on top through Monolog channels.
On a busy store these accumulate steadily, but the growth is manageable when the store runs in production mode with normal error rates. The file that turns growth into a problem is debug.log.
Debug logging left on in production
Debug logging is controlled under Stores, Configuration, Advanced, Developer, Debug, through the "Log to Files" setting. In developer mode it is on, and it writes a line for a large share of what Magento does.
Left enabled on a production store, debug.log is frequently the fastest-growing file on the server. We find it running on stores that were switched to production mode incorrectly, or never fully moved out of developer mode after launch.
Confirm the deploy mode with bin/magento deploy:mode:show. A production store should report production, and debug file logging should be off unless someone is actively diagnosing an issue.
When the disk fills, the site goes down
Unbounded logs are dangerous because the failure is sudden, not gradual. The store runs normally right up until the partition is full.
At that point Magento cannot write session data, cache files, or its own logs, and requests start failing. The root cause is a log file nobody was watching, which is a frustrating way to take an outage.
Set up log rotation
On a Linux server, logrotate solves this in a few lines. Point it at the Magento log directory and let it cap the history:
/var/www/magento/var/log/*.log {
weekly
rotate 8
compress
missingok
notifempty
copytruncate
}The copytruncate option matters here, because it lets rotation work without Magento needing to reopen its log file handles. Adjust weekly and rotate 8 to the retention your team actually needs.
Turn off what you do not need
Rotation caps the size, but the cheaper fix is to stop writing logs you will never read. Turn off debug file logging in production, and keep the store in production mode.
If a specific extension is flooding its own log with warnings, the real fix is the extension, not a bigger disk. A log growing by gigabytes a day is telling you about a defect, not just a housekeeping task.
Magento can also send logs to syslog instead of files, configured in the same Developer section. On a server where a central logging system already handles rotation and retention, that keeps var/log from being the store of record at all.
What else eats the disk
Logs are the usual culprit, but they are not the only thing filling a Magento partition. While you are checking disk usage, look at these too:
var/report/, which stores a file for every uncaught exception.var/cacheandvar/page_cache, if the store uses file-based caching instead of Redis.generated/, which can grow large and stale across deploys.pub/media, where product images and, sometimes, unexpected uploads accumulate.
Running du -sh against those directories tells you where the space actually went in a few seconds.
var/report and the inode trap
The var/report/ directory earns special attention, because it can take a store down while the disk still shows free space. Every uncaught exception writes another small file here, and on a busy store that is thousands of files a week.
The problem is not their size. It is their count. A filesystem tracks two separate limits: disk space, the bytes the files hold, and inodes, the number of files, folders, and symlinks it can address at all.
Every individual file uses exactly one inode, no matter how small it is. A million tiny report files consume a million inodes, and once inodes run out the server reports "no space left on device" even though df -h shows plenty of room. Check the real limit with df -i.
var/report/ can exhaust addressable inodes long before it fills the disk, so clear it on a schedule, at least every 90 days.Before you delete those reports, do something useful with them. Zip the directory, pull the archive down, and actually read a sample of what is inside.
Each report is a stack trace from a real failure on your store. Reading a batch of them often surfaces a recurring problem you did not know was there, and you may find a few clear culprits behind errors customers have been hitting for months.
Managing both numbers, space and inode count, is what keeps the filesystem healthy. Treat them as one combined limit and the store runs cleaner, with fewer of the outages that free disk space alone failed to predict.
Watch the disk before it fills
Rotation stops the logs from growing without bound, but you still want to know when disk usage is climbing for any reason. A full partition is an outage regardless of what filled it.
A one-line check tells you where you stand:
df -h && du -sh var/log var/report generated pub/mediaBetter still, alert on it. A simple cron that emails when a partition passes eighty percent on either space or inodes turns a silent outage into an early warning you can act on during business hours.
Keep it boring
Disk pressure from logs is one of the most preventable outages a Magento store can have. Rotation, production mode, and a periodic glance at disk usage are enough to keep it from ever becoming an incident.
Knowing whether your logs are bounded, your debug logging is off, and your disk has headroom is basic platform hygiene. It is also exactly the kind of quiet risk a structured review surfaces before it turns into a 2am page.