Every time an app crashes, spins forever, or panics the kernel, macOS quietly records a detailed report. Over months or years those files accumulate until you decide to delete crash logs on Mac and discover a folder you never knew existed. This guide explains exactly where those reports live, what they contain, how much space they typically consume, and how to remove them safely — whether you prefer Finder, Terminal, or a one-click tool.
What Are DiagnosticReports, and Why Do They Pile Up?
macOS writes diagnostic data to a handful of dedicated directories. The primary one is ~/Library/Logs/DiagnosticReports, which stores per-user crash and hang reports. A parallel system-level directory at /Library/Logs/DiagnosticReports captures crashes that occur before a user logs in, or that belong to system daemons running as root. A third location, /var/db/diagnostics, holds the lower-level unified logging database, though that is managed by the OS itself and not safe to manipulate directly.
Each crash produces at least one .ips (Incident Progress Summary) file. Older macOS versions used .crash and .diag extensions; you may find all three formats mixed together depending on how long the Mac has been in service. Hang reports produce .hang files, while wakeup failures create .wakeups files. None of these files are needed for day-to-day operation — they exist so developers and Apple support engineers can diagnose repeated failures after the fact.
Where Crash Logs Live on macOS Sequoia and Tahoe
| Location | File types | Who writes it | Typical size |
|---|---|---|---|
~/Library/Logs/DiagnosticReports/ |
.ips, .crash, .hang, .wakeups | User-space app crashes & hangs | 1 KB – 10 MB per file; 50–500 MB total on active Macs |
/Library/Logs/DiagnosticReports/ |
.ips, .crash | System daemons, kernel extensions | A few MB; requires admin password to remove |
~/Library/Logs/ |
App-specific .log folders | Third-party apps (varies widely) | 10 MB – several GB on developer Macs |
/Library/Logs/ |
System service logs | macOS services, installers | Typically < 200 MB |
/private/var/log/ |
syslog, wifi.log, install.log | Unix subsystem | Managed by newsyslog; usually < 50 MB |
Is It Safe to Delete Crash Logs on Mac?
Yes. Crash reports are retrospective documentation — they record what already went wrong. Deleting them does not affect app stability, OS behavior, or any user data. The next time an app crashes, macOS simply writes a fresh report. The only reason to keep old reports is if you are actively debugging a recurring crash and want a history to share with a developer. For most users, crash logs older than a week or two have zero practical value.
What you should not delete is the unified log database under /var/db/diagnostics and /var/db/uuidtext. Those directories back the log command-line tool and Console.app, and removing them can cause the logging subsystem to rebuild itself at next boot, temporarily degrading performance. Stick to the DiagnosticReports directories and the named app log folders in ~/Library/Logs/.
How to Delete Crash Logs on Mac Using Finder
- Open Finder, then in the menu bar choose Go > Go to Folder… (or press Shift ⌘ G).
- Type
~/Library/Logs/DiagnosticReportsand press Return. - Press ⌘ A to select all files, then move them to the Trash with ⌘ Delete.
- Repeat for
~/Library/Logs/to review and remove per-app log folders you no longer need. - For system-level reports, go to
/Library/Logs/DiagnosticReports. You will be prompted to authenticate with your administrator password before files can be moved to the Trash. - Empty the Trash to reclaim the space immediately.
If you want to be selective, sort by Date Modified inside the folder and remove only files older than 30 days. Files dated within the last week may still be useful if you are troubleshooting an active problem.
How to Delete Crash Logs on Mac Using Terminal
Terminal gives you a one-liner that handles both the user and system directories in a single pass.
To remove all reports in your user folder:
rm -rf ~/Library/Logs/DiagnosticReports/*To also clear the system-level directory (requires admin rights):
sudo rm -rf /Library/Logs/DiagnosticReports/*If you prefer to remove only files older than 30 days without touching recent ones:
find ~/Library/Logs/DiagnosticReports -mtime +30 -deleteThe -mtime +30 flag matches files whose modification date is more than 30 days in the past. Adjust the number to taste.
Checking Space Before and After
To see how much space the folder is consuming before you clear it, run:
du -sh ~/Library/Logs/DiagnosticReportsThen run the same command afterwards to confirm the deletion worked. On a developer Mac that has been in use for a few years it is common to find 200–600 MB of accumulated .ips and .crash files.
Other Log Directories Worth Reviewing
While you are in cleaning mode, a few adjacent folders are worth a look. These are not crash reports, but they can accumulate significant size over time:
~/Library/Logs/— Many apps write their own log subfolders here. Adobe, Spotify, and various background updaters are frequent contributors. Check for folders whose parent app you no longer use./Library/Logs/— System service logs including installer logs (install.log) and mdworker logs from Spotlight indexing. Usually safe to clear the contents of individual files, not the directories themselves.~/Library/Application Support/CrashReporter/— An older staging area used by some apps on pre-Ventura systems. May contain.plistfiles that are safe to delete.
For a comprehensive view of what else is swelling your storage — caches, derived data, leftover app support files — the guide on what is System Data in Mac storage explains why the system data category on your Mac can balloon and where to look first.
Preventing Crash Log Buildup Over Time
macOS does not enforce a hard cap on the size of DiagnosticReports by default (unlike /private/var/log, which is rotated by newsyslog). The folder will keep growing until you manually clean it. A few habits that help:
- Quarterly cleanups. Schedule a reminder every three months to open the folder and delete everything older than 60 days.
- Investigate recurring crashes. If the same app is producing a new crash report every day, the real fix is updating or replacing that app — not just deleting its reports.
- Use a dedicated cleanup tool. A tool like Crumb can audit log and cache directories across your entire Mac, show you sizes before you commit, and surface folders you might otherwise miss — including system-level reports that require admin access.
If you suspect broader storage pressure from caches and other junk, the overview on how to clear the system cache on Mac covers the full picture alongside diagnostic logs.
What Happens to Crash Reports After You Delete Them
Nothing breaks. Apps do not read their own past crash reports. macOS Feedback Assistant may have already synced any reports it needed to Apple's servers if you opted into analytics sharing (System Settings > Privacy & Security > Analytics & Improvements). After deletion, the next crash creates a new report from scratch. On Apple Silicon Macs running macOS Sequoia or Tahoe, the .ips format is the dominant type, and these files are written in JSON-like plaintext, making them easy to read in a text editor if you are curious about a specific crash before removing it.
In short, crash logs are like old receipts: useful briefly, and then just clutter. Clearing them regularly is a low-risk, high-reward part of routine Mac maintenance.