Open Finder, press Shift + Cmd + G, type ~/Library/Logs/DiagnosticReports, and hit Return. On an actively used Mac you will likely find hundreds of files — some from apps you have not opened in months, others from crashes that happened years ago. Add the broader system log directories and you are looking at anywhere from a few hundred megabytes to several gigabytes of data that serves no ongoing purpose on most Macs.
This guide explains exactly what system logs and crash reports are, where macOS stores them, how large they typically grow, when you should keep them, when you can safely delete them, and the fastest way to clear them using TrimyMac or manually via Finder and Console.
Crash reports on Mac are diagnostic files automatically generated by macOS whenever an application terminates unexpectedly. They record the full stack trace, memory layout, and hardware state at the moment of the crash. macOS stores them as
.crash or .ips files in ~/Library/Logs/DiagnosticReports. They are used by developers to identify bugs and by Apple to collect crash telemetry, but they have no effect on your Mac's day-to-day operation and accumulate indefinitely unless you clear them.
What Are System Logs on Mac?
macOS is a verbose operating system. Every daemon, framework, kernel extension, and user-space application has the ability to write diagnostic messages to disk. These messages — collectively called system logs — record events ranging from routine startup sequences to network activity, permission checks, driver state changes, and software update progress. They exist primarily to help developers and system administrators diagnose problems after the fact.
Per-application log files live in ~/Library/Logs. You will find a subfolder for almost every app on your machine here: Adobe applications write verbose crash and update logs, Apple's own apps like Mail and FaceTime record activity logs, third-party utilities log their own diagnostic data. Over time, many of these folders accumulate logs from events that happened months or years ago.
System Log Locations
macOS writes logs across several directories depending on the scope of the process generating them:
The ~/Library/Logs path is the most relevant for regular users — it contains per-app log folders written by applications running under your account. /var/log is managed by macOS itself and includes system-level logs like the kernel log, install logs, and fsck output. /Library/Logs contains logs from system-wide processes and installers.
The log format varies by application. Older apps write plain-text .log files. Modern apps on macOS Monterey and later use the Unified Logging system, which writes compact binary .logarchive bundles. Some apps — particularly those from Adobe, Microsoft, and older Unix-heritage utilities — write their own proprietary formats in subfolders. All of these accumulate without any automatic expiry unless the app itself manages rotation.
What Are Crash Reports on Mac?
When an application crashes on macOS — whether due to a memory access violation, an unhandled exception, a watchdog timeout, or any other fatal error — the operating system automatically generates a detailed diagnostic file before terminating the process. This file is a crash report.
Crash reports are stored in ~/Library/Logs/DiagnosticReports for user-space application crashes and in /Library/Logs/DiagnosticReports for crashes from system-level processes. The folder may also contain .spin files (generated when an app stops responding) and .diag files from certain background diagnostic routines.
Crash Report Location & File Types
DiagnosticReports contains several distinct file types, each generated by a different triggering condition:
.ips files — the modern crash report format introduced with macOS Monterey. IPS stands for "incident process state." These are JSON-based structured files that include the full stack trace, register states, binary images loaded at crash time, and metadata. They replace the older .crash text format but contain the same information in a machine-readable structure.
.crash files — the legacy plain-text crash report format, still generated by some older apps and by certain macOS subsystems for compatibility. Human-readable and structured in well-defined sections: process info, exception type, crashed thread, and binary images.
.spin files — generated by macOS's spinning wait-cursor detection when an app stops responding to the main run loop for several seconds. These are not crashes but indicate hangs. Each spin report captures a series of thread samples showing where execution was stuck.
Typical size: 50 MB – 500 MBHow Large Do They Get?
Individually, log files and crash reports are small — a single .ips file is typically 50–300 KB, and most per-app log files are under a megabyte. The problem is accumulation. macOS does not impose a maximum age or total size cap on these directories, so they grow unchecked for as long as you use the machine.
| Location | Contents | Typical Size After 1 Year | Typical Size After 3+ Years |
|---|---|---|---|
~/Library/Logs |
Per-app log folders (Adobe, Apple, third-party) | 100 – 400 MB | 500 MB – 2 GB |
~/Library/Logs/DiagnosticReports |
.ips, .crash, .spin files |
50 – 200 MB | 200 MB – 1 GB |
/Library/Logs |
System-wide installer and daemon logs | 50 – 150 MB | 150 – 600 MB |
/var/log |
Kernel, fsck, install, auth logs | 20 – 80 MB | 80 – 300 MB |
Developer Macs tend to accumulate crash reports faster than consumer machines because development builds crash more frequently than production software, and Xcode-related processes (the simulator, the build system, SourceKitService) are notoriously prolific crash report generators. On a Mac used for active iOS or macOS development, ~/Library/Logs/DiagnosticReports alone can reach 1–2 GB over a few years.
Adobe Creative Cloud applications are particularly heavy log writers. If you run Photoshop, Illustrator, Premiere Pro, or After Effects, you will often find multiple gigabytes of logs in subfolders of ~/Library/Logs/Adobe — crash logs, update logs, media encoder logs, and installer traces from every version update over the lifetime of your Creative Cloud subscription.
Are System Logs and Crash Reports Safe to Delete?
The short answer is yes — for the vast majority of users, system logs and crash reports are completely safe to delete at any time. They are diagnostic artifacts, not operational data. Deleting them does not affect the stability of your Mac, does not prevent apps from launching, and does not disable any system functionality.
There is one meaningful exception to consider before you delete everything: if you are experiencing a recurring crash or unexplained system instability that you have not yet diagnosed, you should read the relevant crash reports first (or export them) before deleting. Once deleted, the history of past crashes is gone, and you lose the ability to compare patterns across multiple incidents.
| File Type | Safe to Delete? | When to Keep |
|---|---|---|
Old .log files in ~/Library/Logs |
Safe | Only if investigating an active issue with that specific app |
.ips crash reports |
Safe | If you plan to file a bug report or are actively debugging the crash |
.crash files |
Safe | Same as above — export via Console before deleting if needed |
.spin hang reports |
Safe | Useful only if an app is currently experiencing repeating hangs you need to diagnose |
| Adobe log folders | Safe | If Adobe Support has asked you to collect them for an open ticket |
| Logs from currently running apps | With care | Do not delete logs for apps currently running — wait until they are quit |
When You Should Look at Crash Reports Before Deleting
Before wiping DiagnosticReports, take two minutes to check whether any of the reports contain information you should act on. There are three scenarios where reading crash reports first is worthwhile:
Recurring app crashes. If an app has been crashing every few days, its crash reports contain the stack trace that pinpoints the failing function. You can copy this information before deleting the reports and attach it to a support request or file a bug with the developer. Without it, the developer has no signal about where in the code the failure is occurring.
Unexplained kernel panics. macOS stores kernel panic logs in /Library/Logs/DiagnosticReports as files starting with Kernel-. If your Mac has been spontaneously restarting, these files may reveal whether the panic is caused by a third-party kernel extension, a hardware fault, or a memory issue. This is valuable information before you delete it.
Developer bug reports. If you are an app developer and you need to submit a crash report to Apple through Feedback Assistant or to a third-party SDK vendor, the .ips files in DiagnosticReports are exactly what those systems expect. Export the relevant file via Console (see below) before clearing the folder.
Manual Cleanup: Console App vs Finder
Method 1: Using the Console App
Console is Apple's built-in tool for reading and managing diagnostic logs. It provides a structured view of crash reports with filters for date, app name, and report type, making it the right choice when you want to review and selectively delete individual reports before clearing the rest.
-
1
Open Console
Press Cmd + Space, type Console, and press Return. Alternatively, navigate to
/Applications/Utilities/Console.appin Finder and double-click it. -
2
Navigate to Crash Reports
In the left sidebar, click Crash Reports under the "Reports" section. Console lists all crash, hang, and spin reports for the current user. You can sort by date, app name, or report type using the column headers.
-
3
Review any reports of interest
Click a report to open it in the detail pane on the right. For any crash you want to keep — perhaps to file a bug report — right-click and choose Reveal in Finder, then copy the
.ipsfile to your Desktop before proceeding. -
4
Select and delete
Press Cmd + A to select all reports, or hold Cmd and click to select specific ones. Press the Delete key, then confirm. Console moves the selected reports to the Trash. Empty the Trash afterwards to reclaim the disk space.
Method 2: Using Finder Directly
For users who want to clear the entire DiagnosticReports folder without reviewing individual files, Finder is the fastest manual path. This method also works for clearing the broader ~/Library/Logs directory.
-
1
Open the Go To Folder dialog
In Finder, press Shift + Cmd + G (or choose Go menu → Go to Folder). A text input sheet drops from the menu bar.
-
2
Navigate to DiagnosticReports
Type
~/Library/Logs/DiagnosticReportsand press Return. Finder opens the folder directly. You can also use~/Library/Logsto see the full per-app log directory. -
3
Select all files
Press Cmd + A to select all files and folders in the directory. If you want to keep any specific files, hold Cmd and click them to deselect before proceeding.
-
4
Move to Trash and empty
Press Cmd + Delete to move selected items to the Trash, or right-click and choose Move to Trash. Then open the Trash and click Empty Trash to permanently free the space.
-
5
Repeat for ~/Library/Logs subfolders
Navigate back to
~/Library/Logsand open the subfolder for any apps whose logs you want to clear — for example~/Library/Logs/Adobe. Delete the contents of those subfolders in the same way. Do not delete the subfolders themselves if they are owned by a running application — only the files inside them.
/Library/Logs and /var/log) require administrator access to modify. You can open them via Finder using Go to Folder, but deleting files there will prompt for your password. For most users, clearing ~/Library/Logs and ~/Library/Logs/DiagnosticReports is sufficient — the system directories are smaller and macOS rotates some of their contents automatically via newsyslog.
TrimyMac: System Logs + Crash Reports Categories
Manual cleanup via Finder works, but it requires remembering multiple paths, navigating them individually, and making judgment calls about which subfolders are safe to clear. TrimyMac's Smart Clean handles all of this automatically with two dedicated scan categories: System Logs and Crash Reports.
TrimyMac: System Logs Category
TrimyMac's System Logs scanner targets log files across ~/Library/Logs, /Library/Logs, and other known log paths. It applies an age filter — by default, files older than 30 days are presented as candidates for removal. Logs written by currently running applications are excluded from results, even if they are older than the threshold, to prevent removing an active log session. The scanner groups results by the owning application so you can see, for instance, that Adobe Premiere has accumulated 600 MB of logs while your total system log footprint is 1.2 GB.
TrimyMac: Crash Reports Category
The Crash Reports scanner covers both ~/Library/Logs/DiagnosticReports and /Library/Logs/DiagnosticReports, surfacing all .ips, .crash, .spin, and .diag files. Results are presented sorted by size and grouped by application name. You can tap into any report in the list to reveal it in Finder or open it in Console for review before deciding whether to delete it. This is useful when you want to triage whether any recent crashes are worth investigating before clearing the full history.
Both categories are part of TrimyMac's concurrent Smart Clean scan. When you run Smart Clean, the System Logs and Crash Reports workers execute in parallel alongside the other nine junk categories. After the scan, files from all categories are presented in a unified review list. You select what to clean, TrimyMac moves the selected items to the Safe Area, and then you confirm permanent deletion from there — the same two-step workflow used across the entire app.
Clear logs and crash reports in under 2 minutes
TrimyMac scans System Logs and Crash Reports as part of Smart Clean — 11 junk categories in parallel, with a Safe Area so nothing is permanently deleted without your confirmation.
Download TrimyMac Free → macOS 13 Ventura or later · Apple Silicon & Intel · No telemetryFrequently Asked Questions
Answers to common questions about system logs, crash reports, and safe cleanup on macOS.
Is it safe to delete crash reports on Mac?
Yes — it is safe to delete crash reports on Mac. Crash reports in ~/Library/Logs/DiagnosticReports are historical diagnostic snapshots that have no bearing on how your Mac or its applications operate. Deleting them does not prevent apps from running, does not cause instability, and does not affect macOS in any way. The only reason to keep crash reports is if you are actively investigating a recurring crash and need the historical data for comparison or for filing a bug report. Once you have addressed any open issues — or decided not to — the files are safe to remove entirely. macOS will automatically generate new crash reports for any future crashes.
What are .ips files on Mac?
IPS files (extension .ips) are the modern crash report format used by macOS Monterey and later. IPS stands for "incident process state." Unlike the older .crash plain-text format, IPS files use a structured JSON schema that allows Apple's crash analytics pipeline to parse and aggregate crash data more efficiently. An IPS file contains the same information as a classic crash report — process name, exception type, crashed thread number, full stack trace, register values, and a list of all binary images (frameworks and dylibs) loaded at crash time — but in a machine-readable format. You can open IPS files with Console.app, which presents the content in a human-readable layout, or open them in a text editor to read the raw JSON. They are safe to delete once you no longer need the information they contain.
How do I clear the DiagnosticReports folder on Mac?
There are two ways to clear the DiagnosticReports folder on Mac. The quickest manual method is to open Finder, press Shift + Cmd + G, type ~/Library/Logs/DiagnosticReports, and press Return. Once the folder opens, press Cmd + A to select all files, then Cmd + Delete to move them to the Trash. Empty the Trash to reclaim the disk space. Alternatively, use TrimyMac's Crash Reports category in Smart Clean: TrimyMac scans both the user-level and system-level DiagnosticReports folders simultaneously, presents the results grouped by app and sorted by size, and moves selected files to the Safe Area before permanent deletion. The TrimyMac approach is faster when combined with a full log cleanup, since it handles both System Logs and Crash Reports in the same pass.
Can I delete system logs on Mac?
Yes — you can safely delete system logs on Mac. Log files in ~/Library/Logs are written by apps to record diagnostic information about their own activity. They are not required for apps to function correctly. Deleting them frees disk space and causes no harm — each app will create fresh log files the next time it runs and needs to write diagnostic data. The only time to keep log files is if you are troubleshooting an active problem with a specific app and the logs contain information about the issue. For logs in system-level directories like /var/log, macOS's built-in log rotation daemon (newsyslog) manages some of these automatically, but the user-facing app logs in ~/Library/Logs have no automatic cleanup, making periodic manual or automated deletion the only way to reclaim that space.
How often should I clear logs and crash reports on Mac?
For most users, clearing system logs and crash reports once every one to three months is a reasonable cadence. The combined directories typically grow at 30–100 MB per month on a casual-use Mac, and at several hundred MB per month on developer machines with active Xcode projects. There is no harm in clearing them more frequently — monthly cleanup prevents large accumulations and keeps your Library/Logs directory easy to navigate when you do need to look at a specific log. TrimyMac Pro includes a scheduled auto-clean option that can handle this automatically on your preferred interval, so the directories are trimmed without you needing to remember to do it.
Will deleting crash reports stop my apps from crashing?
No — deleting crash reports has no effect on app stability. Crash reports are written after a crash occurs; they are a record of what happened, not a cause of crashes. If an app is crashing repeatedly, the underlying cause is a bug in the app, a compatibility issue with your macOS version, a corrupted preference file, or a hardware problem. Clearing crash reports removes the historical record of those crashes but does not address the root cause. If you are experiencing repeated crashes, read the relevant crash reports in Console first to identify which function is failing, then search for that error online or contact the app developer with the crash details before clearing the reports.
What is the difference between .crash and .ips files on Mac?
Both .crash and .ips files are crash reports, but they use different formats. The .crash format is the older plain-text format that macOS has used since Mac OS X. It is human-readable without any special tools — you can open it in any text editor. The .ips format was introduced with macOS Monterey as part of Apple's upgrade to their crash diagnostics pipeline. IPS files contain the same information but use a structured JSON format that is more compact and easier to parse programmatically. On modern Macs running macOS Monterey or later, new crashes generate .ips files; older apps and certain system processes may still generate .crash files for backward compatibility. Both formats are safe to delete and are handled identically by TrimyMac's Crash Reports scanner.