In short
- Magento writes its errors to files in the
var/logfolder and never empties them. - An FTP client is enough to check their size. Above 500 MB, log rotation is not in place.
- Log rotation archives these files every night and deletes the oldest ones. It is a server setting, done once.
- A file that grows very fast often points to a recurring error that needs fixing.
Contents
Why Magento 2 logs keep growing
A log file is your store’s logbook, on Magento 2 and Adobe Commerce alike. Each time something goes wrong, Magento adds a line: a payment declined by the bank, a crashing extension, a missing product. These notes are precious when you need to understand an outage.
The catch is that Magento never tears out the old pages. It keeps writing at the end, day after day. The two files that grow the most are usually system.log and exception.log. The second one holds the full details of every error and is often the heaviest.
Disk usage of a store
100 GB disk, logs growing by 2.5 GB a week
Show the values
| Week | Without log rotation | With log rotation |
|---|---|---|
| 0 | 55% | 56% |
| 4 | 65% | 56% |
| 8 | 75% | 56% |
| 12 | 84% | 56% |
| 16 | 95% | 56% |
| 18 | 100% (full) | 56% |
| 20 | 100% (full) | 56% |
For developers
Magento logs through Monolog. Its handler, Magento\Framework\Logger\Handler\Base, extends Monolog’s StreamHandler: it appends to the file and has no built-in rotation. Monolog recommends leaving rotation to the system tool, logrotate.
Check the size of Magento logs in var/log
No technical skills needed. Connect to your store with an FTP or SFTP client (FileZilla, Cyberduck, WinSCP), or with your hosting provider’s file manager. Your hosting provider or agency gave you the credentials.
- Open the Magento folder, the one that contains
app,pubandvar. - Go into
var, then intolog. - Look at the Size column.
| Name | Size | Modified |
|---|---|---|
| .. | ||
| cron.log | 212 MB | today 09:41 |
| debug.log | 3 MB | 12/03/2026 |
| exception.log | 1.8 GB | today 09:40 |
| system.log | 640 MB | today 09:41 |
How to read the sizes. A few megabytes, even a few dozen, is normal. Above 500 MB for system.log or exception.log, log rotation is almost certainly not in place.
Log rotation, in plain words
Every night, the server sets aside the previous day’s file, compresses it and starts a fresh, empty file. Archives that are too old, for example more than two weeks old, are deleted. The total size stays stable, and you keep enough history to investigate a recent incident.
- Today system.log Magento writes here
- Yesterday system.log.1 Readable archive
- Day before system.log.2.gz Compressed archive, much lighter
- … system.log.14.gz Last archive kept
- 15 days
system.log.15.gzDeleted
Not technical? What to ask your hosting provider
Log rotation is set up on the server. That is the job of your hosting provider, your agency or whoever manages the server. Many Magento hosting providers already have a tool for it: asking is often enough. Here is a message ready to send:
Hello,
The log files of our Magento store (var/log/system.log and var/log/exception.log) keep growing without limit: exception.log is now over 1 GB.
Could you set up rotation for the Magento logs: nightly archiving and compression, with 14 days kept?
Could you also check whether an error keeps repeating in exception.log?
Thank you.
You manage the server: configure logrotate for Magento on Debian or Ubuntu
On Debian and Ubuntu, logrotate is part of the standard installation and runs once a day, shortly after midnight. It already rotates the system and web server logs, but not Magento’s. You just need to add one file.
-
Find the owner of the log folder. Rotation will run as this user. Replace the path with your store’s:
Terminalstat -c '%U %G' /var/www/store/var/logThe answer is, for example,
www-data www-data. -
Create the file
/etc/logrotate.d/magentowith this content, adjusting the path and the user:Content of /etc/logrotate.d/magento/var/www/store/var/log/*.log {su www-data www-datadailyrotate 14missingoknotifemptycompressdelaycompresscopytruncate}
What each line means:
- Line 1 Every .log file in Magento's log folder. Replace the path with your store's.
- su Run as the owner of the folder, the answer from step 1.
- daily, rotate 14 One rotation a day, fourteen archives kept, so two weeks of history.
- missingok, notifempty Do not stop if a file is missing, and leave empty files alone.
- compress, delaycompress Compress the archives, except the previous day's, which stays readable as is.
- copytruncate Copy the file, then empty it in place instead of moving it (see the box below).
-
Check the configuration without changing anything, then run a first rotation:
TerminalDry run: shows what would be done, without changing anything sudo logrotate -d -f /etc/logrotate.d/magento First rotation, right now, then check sudo logrotate -f /etc/logrotate.d/magento ls -lh /var/www/store/var/log/The dry run should print
log needs rotatingfor each file, thencopyingandtruncating. After the real rotation, you should seesystem.logback to zero and a copy namedsystem.log.1. Without this first manual rotation, logrotate would only record the files on the first night and start rotating them the night after. From then on, it takes care of it on its own.
A file that grows too fast often hides an error
Rotation limits the space used, but it does not tell you why a file grows. An error repeated on every page view can fill exception.log in a few hours. It can also slow the store down or get in the way of purchases. If a file grows past 500 MB in a single day, have your developer open it and look for the recurring error.
Another common cause is the debug log, which fills debug.log. Adobe turns it on by default as long as the store is not in production mode, and it is sometimes switched on while troubleshooting and then forgotten. In production, it must be off:
Empty or delete Magento logs by hand?
Emptying a large log over FTP helps on the day, with no risk for the store: Magento keeps writing into the emptied file. Deleting it works less well: as long as a background process keeps the file open, the space only comes back when that process stops. Either way, the problem comes back. Only rotation solves it for good.
Tocsin24 warns you before the disk is full
Tocsin24 regularly records the free space on your store’s server and works out how fast it is filling up. It also reads system.log and exception.log to group your store’s errors, and warns you as soon as one of these files goes past 500 MB.
Espace disque
Espace libre sur le serveur du site.
Erreurs de l'application
Logs Magento lus par le module Tocsin24, sans accès à créer chez votre hébergeur.
- var/log/system.log 42 Mo écrit il y a 2 min
- var/log/exception.log 1,8 Go écrit il y a 3 min Rotation absente
Nous en lisons seulement les lignes récentes : la détection n'est pas gênée. Pour éviter de saturer le disque de la boutique, demandez à votre hébergeur ou à votre agence d'activer la rotation des logs Magento (archivage et compression réguliers).
Application screens with example values.
Frequently asked questions
Can log rotation break my store?
No. It only touches the log files, which Magento recreates on its own. The store keeps running during rotation.
Can I turn off system.log or exception.log?
Magento has no setting for that, and you would lose the only record of an outage. Only the debug log can be turned off. For the others, rotate the files and fix recurring errors.
How many days of history should I keep?
Two weeks is usually enough to understand an incident. Keep more if a contract requires it, while keeping an eye on the space the archives take.
Is a Magento log rotation extension good enough?
Some exist, but they depend on Magento's cron, so when cron is down, rotation stops too. logrotate runs outside Magento, and it is the tool recommended by Monolog, the logging library Magento uses.
My disk is filling up but the logs are small. What should I check?
The var/report folder, which keeps one file per error shown to visitors, backups left on the server, and the web server logs. Your hosting provider can tell you which folder takes the most space.
Cédric has been building Magento stores for 18 years and holds the Adobe Commerce Developer Expert certification. He created Tocsin24 to monitor the security and health of Magento 2 stores and WordPress sites.
Adobe Commerce Developer ExpertVerify the certification on Adobe’s website