How to find application log files on macOS
~/Library/Logs, /Library/Logs, sandbox containers and the unified log: the four places a Mac application can be writing, and how sandboxing moves the path.
macOS looks tidier than Windows about this and mostly is: there are real conventions, and applications mostly follow them. The complication is sandboxing, which takes an application that follows the conventions perfectly and moves its entire Library directory somewhere else.
The four places
| Location | Used for |
|---|---|
| ~/Library/Logs | Per-user application logs. The convention, when an app follows it |
| ~/Library/Application Support | Per-user state. Cross-platform apps keep a logs folder in here instead |
| /Library/Logs | One copy for every account. Installers, daemons, system components |
| /var/log | The Unix underneath. System daemons, and anything ported from Linux |
~/Library is hidden in Finder. Open it with Go > Go to Folder (Shift+Cmd+G) and type the path, or hold Option while the Go menu is open.
Applications written for the Mac first tend to use ~/Library/Logs properly: Spotify writes to ~/Library/Logs/Spotify/. Applications ported from somewhere else usually keep their logs beside the rest of their state instead - Slack uses ~/Library/Application Support/Slack/logs/, and Visual Studio Code ~/Library/Application Support/Code/logs/. Both habits are common enough that checking only one of the two directories is how people conclude an application does not log.
What the sandbox does to a path
A sandboxed application cannot write to ~/Library directly. macOS gives it a container of its own and redirects everything into it, so the path it thinks it is writing to is not the path you need to open:
~/Library/Containers/<bundle-id>/Data/Library/Logs/
1Password is a clean example: ~/Library/Containers/com.1password.1password/Data/Library/Logs/1Password/. The tail of that path is exactly what an unsandboxed application would have used; everything before Data/ is the sandbox.
Applications that share data between several of their own processes, or with an extension, use a group container instead - ~/Library/Group Containers/<team-id>.<group>/. Microsoft Teams logs under ~/Library/Group Containers/UBF8T346G9.com.microsoft.teams/, where UBF8T346G9 is Microsoft’s team identifier and never changes.
Sandboxing follows from how the application was distributed, which is why the same application can have two different paths on the same Mac. That is covered in why log paths differ between installer types.
The unified log
Since macOS 10.12 the system has its own structured log, and a lot of what used to go to a file goes there instead. It is not a file you can open: it is a binary store you query.
log show --predicate 'subsystem == "com.docker.docker"' --last 1h log stream --predicate 'process == "1Password"' --level debug
Console.app is the same data with a window around it, and its sidebar also lists crash reports, which live in ~/Library/Logs/DiagnosticReports/ as .ips files. A crash report is the first thing to read when an application quits rather than misbehaves.
Finding it anyway
Reproduce the problem, then ask the filesystem what changed. Because sandbox containers sit under ~/Library too, one search covers both cases:
find ~/Library /Library/Logs -type f \( -name '*.log' -o -name '*.txt' \) -mmin -5 2>/dev/null
If that finds nothing, the application may be writing to the unified log rather than to disk. Try log stream --process <name> and reproduce the problem again.
Search the catalogue for the application by name and it will give you the exact path, container and all.