Mac log files and crash reports: where they are and what to keep

Most Mac log files are safe to delete. The logs and crash reports in your own Library folder are records of what apps did and why they failed, and nothing on your Mac needs them to work. Apps start new logs as they run, and macOS writes a new report the next time something crashes.

What's worth keeping is the evidence for a problem you haven't solved yet: the crash reports of an app that keeps quitting, the logs a developer or Apple Support asked for, the report from a restart you don't understand. Keep those until the problem is fixed, and let the rest go.

The system's own logs are a different matter. The unified log and the text logs in the hidden /private/var/log folder are managed by macOS, which keeps them to a set size by removing the oldest entries. Leave them alone.

Logs are rarely what fills a Mac. Together they usually take from about 100 MB to a few gigabytes. The sections below show where each kind lives, how to tell when one has run away, what to keep, and how to clear the rest in Console or Finder.

Where Mac log files and crash reports live

A Mac keeps logs in several places, and they're not all equal. Some are yours to clear, some need an administrator, and some belong to macOS.

Location	What's there	Level	Who looks after it
~/Library/Logs	Logs your apps and your account's services write	Safe	You, or the apps that write them
~/Library/Logs/DiagnosticReports	Crash, spin and diagnostic reports about your apps	Safe	You, in Console or Finder
/Library/Logs	Logs of helper tools, installers and services for every user	Usually safe	An administrator
/Library/Logs/DiagnosticReports	Reports about the system and its services	Safe	An administrator, in Console or Finder
/private/var/log	Text logs such as system.log, install.log and wifi.log	Managed by macOS	macOS, which rotates them
/private/var/db/diagnostics	The unified log, where most messages go	Managed by macOS	macOS, which keeps it to a set size
/cores	Core dumps, only if they've been turned on	Review first	You, if you turned them on

Your Logs folder

~/Library/Logs is where apps and macOS services write logs for your account. Apple's documentation describes it as the place for log files of the console and specific services, and the Console app can read them. Each app usually has its own folder or file, named after the app.

The folder is hidden like the rest of your Library. In Finder, choose Go › Go to Folder, type ~/Library/Logs and press Return. Or hold the Option key while you open the Go menu, choose Library, then open Logs.

Crash, spin and diagnostic reports

When an app crashes, stops responding or uses an unusual amount of resources, macOS writes a report. Reports about your apps go in ~/Library/Logs/DiagnosticReports; reports about the whole system go in the same folder inside /Library/Logs.

The file's ending says what kind of report it is, and each name starts with the app or process, followed by the date and time.

Report	File ending	What it records
Crash report	.ips	An app or process that quit unexpectedly
Spin report	.spin	An app or process that stopped responding
Log report	.log, ._log or .its	Events while the system or an app was working
Diagnostic report	.diag or .dpsub	Resource use, such as disk writes, and response times

Logs for every user

/Library/Logs, in the Library folder at the top of your disk, holds logs that apps with helper tools, installers and some services write for the whole Mac. Most items there belong to the system, so moving them needs an administrator's name and password.

The unified log and /private/var/log

Since macOS Sierra, apps and macOS record most of their messages in the unified log. Apple's documentation says it keeps log data in memory and on disk rather than in text files, and you read it in the Console app. On disk it lives in /private/var/db/diagnostics, with supporting data in /private/var/db/uuidtext.

Not every message reaches the disk. Apple's documentation says debug messages stay in memory, and info messages are written only when someone collects them with a logging tool. Notices, errors and faults are compressed and written to disk, and when that store passes a set size, the oldest messages are removed to make room.

A few text logs remain in /private/var/log: system.log, install.log for software installs and updates, wifi.log and others. macOS rotates them on a schedule, so you'll see system.log next to numbered, compressed older copies, with the oldest removed as new ones arrive.

What changed between macOS versions?

The places are much the same on macOS 27 Golden Gate and macOS 26 Tahoe, and Console works the same way on both. Older Macs and older advice differ in a few ways worth knowing, because many cleanup guides were written for them.

What	macOS 27 and 26	Older versions
Most log messages	The unified log, read in Console	Text files in /private/var/log, before macOS Sierra
Crash report files	Mostly .ips	Often .crash, which you may still find
Analytics settings	System Settings › Privacy & Security › Analytics & Improvements	System Preferences › Security & Privacy › Privacy, before macOS Ventura
Storage settings	System Settings › General › Storage	About This Mac › Storage › Manage, before macOS Ventura

Advice to clear /private/var/log dates from the time when that folder held most of the Mac's logs. Today most messages go to the unified log, so the text logs left there are small, and macOS rotates them anyway.

How much space do logs take?

On most Macs, logs and crash reports together take from about 100 MB to a few gigabytes. That's small next to snapshots, caches, backups or developer files, which is why clearing logs rarely solves a full disk on its own. The post on storage that keeps filling up covers what does grow by itself.

Why logs are rarely the problem

The biggest logs are the ones macOS manages, and it caps them. Howard Oakley of The Eclectic Light Company, who studies the unified log closely, measures its main store at a target of roughly half a gigabyte, with its supporting text sometimes over 1 GB.

Most apps trim their own logs too. Visual Studio Code keeps logs for recent sessions and removes older ones; Gradle deletes its daemon logs after 14 days; Homebrew's regular cleanup removes older install logs.

When a log runs away

Logs become a space problem when something goes wrong repeatedly. An app stuck in a loop can write the same error thousands of times a minute, and an app that crashes at every launch leaves a new report each time.

The signs are easy to spot once you look: one log file far larger than the rest, a log whose date keeps changing while you watch, or dozens of reports with the same app's name. In each case the log is a symptom. Removing it frees the space for a while; fixing or removing the app stops it coming back.

How to find large log files

1. In Finder, choose Go › Go to Folder, type ~/Library/Logs and press Return.
2. Choose View › as List, then View › Show View Options, and select Calculate all sizes.
3. Click the Size column heading to put the largest items first.

Do the same for /Library/Logs. If neither folder holds more than a few hundred megabytes, logs aren't where your space went, and the guide to System Data is a better place to look.

A worked example

Say Finder shows your Logs folder at 2.5 GB. Sorted by size, one app's folder holds 2 GB, its newest file dated today, and DiagnosticReports holds forty reports with the same app's name.

That's one app with a problem, not a Mac full of logs. Check the newest report's version against the developer's latest release, and update or remove the app. Keep the newest report until the crashes stop, then clear the app's logs and the older reports.

The other half gigabyte, spread across many apps, isn't worth the time. It's what a working Mac looks like.

Are Mac log files safe to delete?

Yes, the ones in your own Library folder, and the crash reports in both DiagnosticReports folders. Apps don't read their old logs to work, and macOS doesn't need old reports. What you lose is the history.

What deleting a log costs

A log is useful only for looking back. Once it's gone, you can't use it to find out why something failed last week, attach it to a bug report, or compare it with what happens next time.

That cost is zero for an app that works fine, and real for one you're still troubleshooting. So the question is never whether a log is safe to delete, but whether it still has something to tell you.

Is it safe to delete crash reports on a Mac?

Yes. A crash report helps a developer or Apple understand a problem, but nothing on your Mac uses it. macOS writes a new one if the app crashes again, and the Console app has its own command to move reports to the Trash.

Look at the names before you clear them. Many reports about one app are a sign that it has a problem worth fixing, and the newest of them is the one a developer would want.

Which logs does macOS clear by itself?

More than you might think. The unified log removes its oldest entries as new ones arrive. The text logs in /private/var/log are rotated, compressed and eventually removed. And Apple's Mac User Guide says that when space is needed, macOS clears caches and logs that are safe to delete.

That's why removing system logs by hand gains nothing lasting. They grow back to the same size, and you've lost the history macOS was keeping in case you needed it.

Does deleting logs make a Mac faster?

No. Writing logs is part of normal work, and an old log sitting on the disk costs nothing until you open it. Clearing logs frees space and nothing else.

The one link to speed runs the other way: an app that's writing errors constantly is using time and disk writes to do it. The fix is the app, not the log.

What to keep, and for how long

Most logs are worth nothing after a few days. A few are worth keeping until a problem is solved, and a very few are worth saving somewhere safe.

Situation	What to keep	For how long
An app keeps crashing	Its newest crash reports	Until it's fixed or you've reported it
A developer or Apple Support asked for logs	Exactly what they asked for	Until the case is closed
Your Mac restarted because of a problem	Recent system reports	Until you've found the cause
An install or update failed	Nothing to keep: install.log is managed by macOS	It stays as long as macOS keeps it
Everything works	Nothing	Clear app logs and reports when you like
You turned on debug logging or core dumps	Only the ones you're examining	Turn them off when you're done

Keep reports for a problem you're still fixing

If an app quits unexpectedly more than once, keep its newest crash report until you've found the cause or heard back from the developer. One recent report is usually enough; dozens of identical ones add nothing.

Keep what support asked for

When a developer or Apple Support asks for logs, they usually name the files or tell you how to make them. Save a copy of what you send, and keep it until the case is closed, because they may ask about a detail later.

What if your Mac restarted because of a problem?

When a Mac restarts unexpectedly and shows a message that it restarted because of a problem, macOS has had what Apple calls a kernel panic. Apple says the most likely cause is faulty software, though damaged or incompatible hardware, including devices you've connected, can cause one too.

Keep recent system reports until you've worked through Apple's steps: updating software, removing plug-ins and enhancement software, disconnecting devices, and running Apple Diagnostics. If panics keep coming, keep the reports in case Apple Support asks for them.

How to view and remove crash reports in Console

Console is the app made for reading logs and reports, and it's the tidiest way to clear reports, because it shows what each one is about before you remove it.

Open Console and find a report

1. Open Console from Applications › Utilities in Finder.
2. In the sidebar, click Crash Reports, Spin Reports, Log Reports or Diagnostic Reports.
3. Click a column heading to sort, for example by date or by process name.
4. Select a report to read it, or double-click it to open it in its own window.

The sidebar also lists Mac Analytics Data and system.log, the legacy system log from /private/var/log. Both are there to read, not to clear.

Can you read the unified log in Console?

Yes, as it's written. Select your Mac in the Devices list on the left, then click Start in the toolbar, and messages from apps and macOS appear in the window as they arrive. Users who aren't administrators need an administrator's name and password to see them.

That's the way to watch a problem as it happens: start the stream, reproduce the problem, and note the time. There's nothing to clear here, because Console reads the log rather than keeping a copy of it.

Who can see which reports?

Console shows two kinds of report. User reports come from apps you've used; system reports come from parts of macOS that affect every user. Administrators can see all of them, while other users see only their own.

The same split decides what you can remove. Your own reports are yours to clear. System reports belong to the Mac, so moving them needs an administrator.

Move reports to the Trash from Console

Select a report and choose File › Move to Trash. To see it in Finder first, choose File › Reveal in Finder. Reports in the Trash still take space until you empty it, and you can put one back until then.

How do you send a crash report to a developer?

Apple's documentation for developers describes the steps. In Console, select Crash Reports, find the app's reports by its name, Control-click the one you want and choose Reveal in Finder. Then drag the file into an email or a support form.

Open the report and read it before you send it. Some reports' names include your Mac's name, and every report describes what the app was doing. If something in it is private, ask the developer what they need from it.

How to read a crash report

You don't need to be a developer to get something useful from a crash report. The first lines tell you what crashed, which version, and when, and that's often enough to decide what to do.

What the header tells you

Every report starts with a header describing where the crash happened. Not every report has every field, but these are the ones worth reading.

Field	What it tells you
Process	The name of the program that crashed, with its process number
Identifier	Its bundle identifier, such as com.example.app
Version	The version of the app that crashed
Date/Time	When it crashed
OS Version	The version of macOS it was running on, with the build number
Path	Where the program was on the disk

What the exception section tells you

Below the header, every crash report has an exception section. Apple's documentation says it records how the process quit, but may not fully explain why. That's the developer's job, so there's no need to work it out yourself.

What matters to you is the pattern. The same app, the same version, crashing the same way every time you do one thing, is worth reporting with that report attached. A crash that happened once and never again usually isn't.

What to do with what you learn

• An old version keeps crashing: update the app. Compare the report's Version with the developer's latest release.
• Crashes started after a macOS update: check the developer's site for a version that supports it, using the report's OS Version.
• A helper or plug-in crashes, not the app: the Process name tells you which; update or remove that component.
• Something you don't recognize crashes often: search for the bundle identifier to find whose it is before you remove anything.

Do logs and reports contain private information?

Some, and macOS limits it. Apple's documentation says macOS replaces parts of a crash report's paths that could identify you with placeholders. The unified log has privacy options that let apps hide sensitive values in their messages.

App logs in your Logs folder are up to each app, and some record file names or account details. That's another reason to read a log before you send it anywhere, and to clear the logs of apps you've stopped using.

How to clear app logs in Finder

For app logs, Finder works well. The one rule that matters: remove what's inside the log folders, not the folders themselves, because some programs, including background jobs, expect them to exist.

Clear your own Logs folder

1. Quit the apps whose logs you're going to remove.
2. In Finder, choose Go › Go to Folder, type ~/Library/Logs and press Return.
3. Open an app's folder, select the log files inside it, and choose File › Move to Trash. For a log that's a single file in the Logs folder, move the file.
4. Leave the DiagnosticReports folder itself in place; remove reports from inside it, or use Console.
5. Use your apps for a while, then empty the Trash.

Clear /Library/Logs

The steps are the same, starting from /Library/Logs. Finder asks for an administrator's name and password to move most items. A service that's writing a log at the time may simply start a new one, which is fine.

What not to touch

Leave /private/var/log and /private/var/db/diagnostics to macOS. They're kept to a steady size, the space comes back within days anyway, and removing them loses the history you'd need if something went wrong.

Don't remove logs from inside apps' data folders either, unless the app or its developer documents that folder as logs. Application Support holds an app's own data, and a file named log there may be part of how the app works.

Why not paste a Terminal command?

Guides that offer a command to delete every log on the Mac skip the Trash, remove the system's managed logs along with the rest, and can't be undone. A typo in such a command can delete far more than logs.

Fake cleanup guides are also a known way to get malware onto a Mac. Console, Finder and each tool's own settings cover everything logs need.

Developer logs

Developer tools write some of the larger and longer-lived logs on a Mac, and several keep them outside the Logs folder. Most of them clean up after themselves; a few only grow.

Tool	Where its logs are	Level	Removed by itself?
Homebrew	~/Library/Logs/Homebrew	Safe	Yes, by its regular cleanup
JetBrains IDEs	~/Library/Logs/JetBrains	Safe	Old versions' folders, when a new major version arrives
Android Studio	~/Library/Logs/Google/AndroidStudio<version>	Safe	No: old versions' folders stay
Simulator	~/Library/Logs/CoreSimulator	Safe	No
Gradle Daemon	~/.gradle/daemon/<version>	Safe	Yes, after 14 days
Claude Code's MCP logs	~/Library/Caches/claude-cli-nodejs	Safe	No
VS Code and Cursor	logs in each app's Application Support folder	Safe	Yes, older sessions

Logs that clean themselves

Gradle removes its daemon logs after 14 days. Claude Code deletes its debug logs, written only while debug logging is on, once they pass its cleanup period, 30 days by default. A new major version of a JetBrains IDE removes the log folders of versions that haven't been updated in 180 days.

• Gradle Daemon logs14 days · Safe
• Claude Code debug logs, by default30 days · Safe
• JetBrains log folders of unused versions180 days · Safe

From each tool's documented behavior, as recorded in the app's catalog. The JetBrains folders go when a new major version is installed. The unified log has no fixed period: it keeps a set size, so a busy Mac holds less time.

Logs that only grow

Some developer logs have no limit. Android Studio keeps a log folder for every version you've run. The Simulator writes a folder of logs for each simulator you start. These are safe to clear with the tool closed.

A Mac that has run many simulators over the years can collect a folder of logs for each of them. The Xcode cleanup guide covers the simulators and the rest of Xcode's data.

Claude Code's logs of its traffic with MCP servers are the one to check. They sit in the Caches folder, one folder per project and server, and include full tool results, so a server that returns images or long documents can make them grow to many gigabytes.

Logs inside apps' data folders

Apps built on Electron, such as Visual Studio Code and Cursor, keep a logs folder next to your settings in their Application Support folders. They trim older sessions themselves, so the folder rarely grows large. If you do clear it, quit the app first, and remove only the logs folder, not its neighbors, which hold your settings and extensions.

Core dumps, sysdiagnose and analytics

A few diagnostic files are much larger than ordinary logs. They exist only if something, or someone, turned them on.

Core dumps in /cores

A core dump is a copy of a crashing process's whole memory, written to the /cores folder at the top of your disk with a name like core followed by the process's number. macOS has them turned off by default; developers turn them on to examine a crash in a debugger.

Because each one holds a process's entire memory, a single core dump can be very large, and they stay until they're removed. If you find files in /cores, someone turned core dumps on.

Keep the ones you still want to examine, move the rest to the Trash, and turn core dumps off again in whatever way they were turned on. New ones are written only while core dumps stay on.

sysdiagnose archives

A sysdiagnose is a bundle of logs and system information that Apple's bug reporting instructions ask for. macOS makes one when the key combination Control-Option-Command-Shift-Period is pressed, and saves it in the hidden folder /private/var/tmp.

Each archive can be large, and pressing the keys by accident leaves one behind. Once you've sent it, or if you didn't mean to make it, you don't need it. Moving it to the Trash in Finder may need an administrator's password.

Mac Analytics data

Console's Mac Analytics Data shows the analytics information macOS gathers, even if you haven't chosen to send it to Apple. Whether it's sent is set in System Settings › Privacy & Security › Analytics & Improvements, with Share Mac Analytics and Share with app developers.

The settings are the same in macOS 27 and macOS 26. Before macOS Ventura, they were in System Preferences › Security & Privacy › Privacy, under Analytics & Improvements.

Does turning off analytics save space?

Not in a way you'd notice. The settings decide whether analytics and crash information are sent to Apple and to app developers. Console shows analytics data either way, and reports are written either way, so turning sharing off is a privacy choice, not a storage one.

How to stop logs piling up again

Logs come back by design. The aim isn't an empty Logs folder but one that stays small without attention.

Fix the crash, not the report

A steady stream of crash or spin reports from one app means the app has a problem. Update it, check the developer's support page, or remove it if you no longer use it. The reports stop when the crashes do.

The same goes for an app that writes errors into its log nonstop. Its log will fill again however often you clear it.

Turn off what you turned on

Debug logging, verbose modes and core dumps are meant for a session of troubleshooting. Turn them off when you've finished, and remove what they wrote.

Clear the logs of removed apps

Dragging an app to the Trash leaves its logs behind, like its caches. Their folders in ~/Library/Logs are named after the app, so they're easy to find and safe to remove.

The guide to uninstalling apps covers the rest of what an app leaves in your Library, and the post on clearing Library caches covers its cache folder.

Put logs in proportion

If your Mac is short of space, logs are worth a two-minute look, not an afternoon. What System Data is on a Mac explains the parts that are usually larger, from snapshots to virtual memory.

How the app does it

Wombit shows what's using your storage and explains every item in plain language, from a catalog written and checked by hand with sources. Select a log folder on the map and you see what it holds, what removing it costs, and its level, with a Move to Trash or Clean Up button.

Your App logs and Crash and diagnostic reports are Safe: they start checked, and only Safe items count in the headline number. Their entries say the log folders themselves stay, because some programs expect them to exist.

• ~/Library/Logs/*

  App logs

  Log files that apps and macOS services write in your Library folder to record what they do.

  Safe · Moves what's inside it to the Trash

• ~/Library/Logs/DiagnosticReports/*

  Crash and diagnostic reports

  Reports macOS saves when an app crashes, stops responding or uses a lot of resources. You can view them in the Console app.

  Safe · Moves it to the Trash

• /Library/Logs/*

  Logs for all users

  Log files that helper tools, installers and macOS services write in the Library folder at the top of your disk.

  Usually safe · Moves what's inside it to the Trash

• /private/var/log

  System log files

  Text log files that macOS and some system services keep in the hidden /private/var/log folder.

  Managed by macOS · Explained only: never removed

• /private/var/db/diagnostics

  Unified log

  The log where macOS and apps record most of their messages, stored in a compressed format that the Console app reads.

  Managed by macOS · Explained only: never removed

• /cores/*

  Core dumps

  Copies of a crashed process's memory that macOS saves in /cores, only when core dumps have been turned on.

  Review first · Moves it to the Trash

Logs in /Library/Logs are Usually safe and need an administrator. Core dumps are Review first and wait for you to choose them. The unified log and /private/var/log are Managed by macOS: explained, left to macOS, never moved.

Developer logs, from Homebrew's to the Simulator's, are explained like everything else and listed in Cleanup by level. Cleanup moves items to the Trash, where you can put them back, and logs every run.

Seeing every log explained is free. Cleanup and items that need an administrator are PRO: one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.