Magento Log Rotation and Disk Pressure

Magento does not rotate its own logs

Magento's standard file logger writes to var/log, but it does not clean those files up for you. Without a separate retention policy, a log keeps growing until the filesystem rejects another write. A full disk is often the first alert.

This failure is separate from database bloat. Database growth can make queries slower over time. Filesystem pressure can stop session writes, cache writes, deployments, and new log entries as soon as the next write fails.

Log rotation gives each file a limit. Production mode keeps routine debug output down, and monitoring gives the team time to act before the limit becomes an outage.

Which files grow, and how fast

The core files in var/log are system.log, debug.log, and exception.log. Extensions can add more files through Monolog channels, which route messages from a specific part of the application.

Log size follows request volume and error rate. A busy store can produce a steady stream of normal production messages without a crisis. debug.log is different because debug output can record routine details for a large share of each request.

That difference creates a common failure pattern: the store looks healthy, then one oversized debug file consumes the remaining space.

Debug logging left on in production

Magento controls file debug logging under Stores, Configuration, Advanced, Developer, Debug, through the "Log to Files" setting. Developer mode commonly leaves this setting enabled, and it can also remain enabled after a manual configuration change.

When file debug logging stays on in production, debug.log is often the fastest-growing file on the host. This happens when a store was never fully moved out of developer mode or when a troubleshooting change was left behind after the incident.

Confirm the deploy mode with bin/magento deploy:mode:show. A production store should report production. Check the "Log to Files" setting separately, and turn it off after active diagnosis ends. A temporary debug setting needs an owner and an expiry time.

When the disk fills, the site goes down

Unbounded logs create a sudden failure. The store can serve requests normally until the partition reaches its limit, then the next write fails.

Magento may be unable to write session data, cache files, generated files, or its own logs. The resulting errors can hide the first useful clue, because the application is failing while it tries to record the failure.

That is how an unattended log turns into an outage. The application did not need a new code deploy to stop; it only needed the filesystem to run out of room.

Set up log rotation

On a Linux server, logrotate can cap the history in a small configuration file. Put the policy under /etc/logrotate.d/ and point it at the Magento log Directory:

/var/www/magento/var/log/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
    copytruncate
}

weekly runs the policy once a week, and rotate 8 keeps eight older copies. compress reduces archive size. missingok skips a file that does not exist, and notifempty skips an empty file.

copytruncate lets rotation work while Magento keeps its existing file handle open. The process copies the current contents and then truncates the original file, so Magento can continue writing without a service restart. Test the policy under normal traffic because entries written during the copy can be missed.

Adjust weekly and rotate 8 to the retention your team needs. A store with high log volume may need daily rotation. A store with compliance or incident-review requirements may need longer retention in a central logging system.

Keep this configuration in host configuration management. A reviewed DIFF makes the policy Reproducible when the server is rebuilt, and the exact log Directory and retention period stay visible to the next engineer.

Turn off what you do not need

Rotation limits the damage, but the first fix is to stop writing output nobody needs. Turn off file debug logging in production and keep the store in production mode.

If one extension floods its own log with warnings, repair the extension after you contain the growth. Buying a bigger disk only delays the same failure. A log growing by gigabytes per day is evidence of a defect or an unexpected workload.

Magento can send logs to syslog instead of local files through the same Developer section. If a central logging system already handles rotation, access control, and retention, it can hold the long-term copy while var/log stays small.

What else eats the disk

Logs are a common culprit, but other Magento Directories can fill the same partition. Check these paths while you measure disk usage:

• var/report/, which can store a small file for each uncaught exception.
• var/cache and var/page_cache, when the store uses file-based caching instead of Redis.
• generated/, which can retain large or stale generated files across deploys.
• pub/media, where product images and unexpected uploads can accumulate.

Run du -sh against those Directories from the Magento root. The output shows where the bytes actually went, which is faster than guessing from the application error.

var/report and the inode trap

The var/report/ Directory needs special attention because it can take a store down while the disk still shows free space. A busy store can create thousands of small report files in a week.

A filesystem tracks two separate limits. Disk space measures the bytes stored in files. Inodes track how many files, Directories, and symlinks the filesystem can address.

Each file uses an inode even when it contains only a few bytes. A million small report files use a million inodes. After the inode limit is reached, the server can report "no space left on device" even when df -h shows free disk space. Check the inode limit with df -i.

Archive the reports before deleting them. Zip the Directory, move the archive to protected storage, and read a sample before cleanup. Reports can contain paths, request data, and other details that deserve controlled access.

Each report contains a stack trace from a failure on the store. A batch review can expose one recurring exception behind errors customers have seen for months. Use that evidence to open a repair task, then let the retention policy remove old reports.

Check both df -h and df -i. Free bytes do not compensate for exhausted inodes, and free inodes do not compensate for a full partition.

Watch the disk before it fills

Rotation handles the files you named, but unexpected uploads, generated files, and report files can still consume the partition. A full partition is an outage regardless of what filled it.

Run this check from the Magento root to see the mounted disk and the largest known Directories:

df -h && du -sh var/log var/report generated pub/media

Run df -i in the same check. Alert when either space or inodes pass a threshold. Eighty percent is a reasonable starting point, but the right threshold depends on how quickly this host grows and how long the team needs to respond.

A cron job can send the alert, and a central monitoring system can keep its history. Test the alert by filling a safe staging mount or lowering the test threshold. An untested alert is only a comment in a configuration file.

Keep it boring

Disk pressure from logs is a preventable Magento outage. Give every log a retention limit, keep file debug logging off in production, and alert on both disk space and inodes.

Review the logrotate DIFF, confirm the policy is Reproducible on a rebuilt host, and inspect the Magento Directories that can grow outside var/log. A short check during business hours is easier than explaining a full filesystem during a 2am outage.