Log files on a Mac that quietly grow for years
· 6 min read
Most logging on a modern Mac is self-limiting: the system log store is capped and rotates, and the files in /var/log are trimmed by maintenance scripts. The ones that grow for years are almost always written by an individual application into ~/Library/Logs, where nothing prunes them. On a Mac that has been in daily use for a long time, a single misbehaving app can be holding several gigabytes there.
Measuring takes one command. The rest of this is knowing which ones to leave alone.
Measure the four places logs live
Run this in Terminal. It asks for your password because two of the paths are outside your home folder:
sudo du -sh /var/log /Library/Logs ~/Library/Logs /var/db/diagnostics
That covers everything worth checking:
/var/logholds classic system log files, including the record of every macOS installation and update/Library/Logsholds logs from software installed for all users, plus system-wide crash reports~/Library/Logsholds logs from apps running as you, and is where the runaway files usually are/var/db/diagnosticsis the unified log store, the binary database behind the Console app
If one of those is large, drill into it:
sudo du -sh /var/log/* | sort -h | tail -10
du -sh ~/Library/Logs/* | sort -h | tail -10
And to find individual files that have got out of hand anywhere in your library:
find ~/Library -type f -name "*.log" -size +100M 2>/dev/null -exec ls -lh {} \;
Which of these are safe to remove
The general answer is that log files are records of what already happened, not data an app needs to work, so removing them does not break software. The exceptions are worth knowing.
~/Library/Logs and /Library/Logs: safe. Delete old app logs freely. Crash reports live in DiagnosticReports subfolders inside both, as thousands of small .ips files, and those are safe too unless you are in the middle of chasing a bug with someone’s support team.
/var/log: safe, with one caveat. install.log and its rotated .gz companions record system updates. Removing them costs you the history of what was installed when, which is occasionally useful and rarely missed. If your Mac has been upgraded across many macOS versions, look for a /var/log/asl folder left over from the old logging system; if it exists and is large, it is stale data nothing reads any more.
/var/db/diagnostics: do not delete by hand. This is the unified log store and macOS manages its size itself. If you genuinely need the space, there is a supported command:
sudo log erase --all
That clears the log history. You lose the diagnostic record the Console app reads, which is exactly what a support engineer would ask you for, so run it only when you have no active problem to investigate.
Anything currently being written: nothing to gain yet. See the next section.
Why deleting a log file sometimes frees nothing
This is the part that wastes an afternoon. You find a twelve gigabyte log file, delete it, empty the Trash, and free space does not change.
The reason is that the application still has the file open. On macOS, deleting a file only removes the name; the data stays on disk until every process that has it open lets go. The app carries on writing into a file that no longer has a name, and you get the space back when you quit the app or restart the Mac, not when you press delete.
You can see this happening:
sudo lsof | grep -i deleted
So the correct order is: quit the application, then delete its log, then restart it. It will create a fresh log and start again from nothing.
Finding the app that is actually responsible
Once you know ~/Library/Logs is heavy, the subfolder names usually name the culprit directly, because apps create a folder under their own name. Sort by size and the answer is normally one folder.
Console gives you the same picture with a graphical view. Open it from Applications, Utilities, and look at the Reports section in the sidebar: log reports, crash reports and diagnostic reports are listed there, and you can reveal any of them in Finder to see the files themselves.
Two causes account for most runaway logs:
Verbose or debug logging left switched on. Some apps have a diagnostic mode intended to be used for a day and then turned off. Check the app’s own preferences before you delete anything, or the file will be back at the same size in a month.
A background process failing repeatedly. A sync client that cannot reach a server, or a helper that crashes and relaunches, can write the same error thousands of times an hour. Deleting the log treats the symptom. Opening it and reading the last twenty lines usually tells you what to fix.
There is a third, less common cause: a diagnostic configuration profile installed at the request of a support team and never removed. If you have ever been asked to install a logging profile, check System Settings, General, Device Management, and remove the profile if it is still listed.
Where logs sit in the bigger picture
Logs are one component of what macOS reports as System Data, and on most Macs they are not the largest one. Caches, swap and Time Machine local snapshots are usually ahead of them, and chasing logs first is a common way to spend an hour for a few hundred megabytes.
If you want the parts of System Data separated before you start deleting, Crumb breaks it into caches, logs, swap, temporary files and leftovers in a read-only audit, alongside Time Machine local snapshots on the internal drive, old iOS backups and swap. Its Ask Crumb feature answers the question this article keeps circling: point it at a file and it explains what the item is, whether it regenerates, and what breaks if it is gone. Nothing is deleted until you approve the plan, and reclaimable removals can be reviewed afterwards. The audit and one full cleanup are free.
The wider view is worth having. What System Data is and how to shrink it covers the categories in order of size, and swap files covers the one that is genuinely not safe to touch.
Questions
Will deleting logs make my Mac faster? No. Log files are written to and rarely read, so their size has no effect on performance. The only reason to remove them is disk space, and on a disk with room, leaving them alone is fine.
Should I run the maintenance scripts to rotate logs?
macOS runs its daily, weekly and monthly maintenance itself, including log rotation, and it catches up if the Mac was asleep at the scheduled time. Running sudo periodic daily weekly monthly by hand does no harm, but on a machine that is used regularly it usually finds nothing to do.
Are crash reports worth keeping?
Only while you are diagnosing something. A folder of .ips files from two years ago has no value to you, and none to a developer either, since they want the crash from the version you are running now.
Is it safe to delete logs from the Console app?
Console shows you reports and lets you reveal them in Finder, and deleting the files it points at follows the same rules as above: app logs and crash reports are safe, the unified log store should be cleared with log erase rather than by removing files.