The short answer: Unified Logs live under /var/db/diagnostics/ plus /var/db/uuidtext/. The log command on macOS reads the binary store plus emits human-readable events. For forensic work, the log show command with predicate filters produces the data feed investigators need. Retention is approximately seven days for the high-volume tracev3 files plus longer for the persistent signpost data.
What Changed When Sierra Replaced Syslog
Before Sierra, macOS used syslog for system messages. Application logs went to /var/log/system.log, kernel messages to /var/log/kernel.log plus per-service logs to per-service files under /var/log/. The model was straightforward but limited: text-based logging with rate caps that throttled high-volume sources plus no structured metadata beyond the message prefix.
Apple introduced Unified Logging in Sierra to address both the rate-cap problem plus the structured-metadata gap. Unified Logging is a binary log format with built-in metadata (subsystem, category, process identifier, sender) plus a streaming write path that handles much higher event rates than syslog could. The trade-off is that the logs are no longer human-readable without the log command plus the underlying binary format requires specialized tooling to parse outside of a running macOS system.
Where the Unified Log Data Lives
The binary log data is split across two main directories. /var/db/diagnostics/ contains the active tracev3 files (the per-process trace data) plus the live signpost data. /var/db/uuidtext/ contains the UUID-to-text translation files needed to render the binary trace into human-readable form. Both directories are needed for offline analysis: a tracev3 file alone is unreadable without the matching uuidtext entries.
For forensic acquisition the entire /var/db/diagnostics/ tree plus the entire /var/db/uuidtext/ tree should be preserved. The two directories together total approximately 5 GB on a typical workstation but can grow significantly larger on systems with high logging volume (developer machines, build agents). Forensic acquisition of a live macOS system needs to handle the locked-file problem: the tracev3 files are open by the log daemon plus require either a Volume Shadow Copy equivalent (APFS snapshot) or an acquisition workflow that pauses the log daemon long enough to copy the files.
The log show Command Is the Primary Interface
On a running macOS system the log show command is the documented interface for reading Unified Logs. The command takes a predicate filter (similar to NSPredicate syntax) plus emits matching events to stdout. For forensic work the common predicates filter by subsystem, by process plus by time range. For example log show --predicate process == ssh --start 2026-06-20 --end 2026-06-22 returns all ssh process log entries within the window. The same predicate language supports compound filters across subsystem plus message content.
For offline analysis the live log show command is not available because the analyst is not running on the source system. The unifiedlogs-parser project (open source, Mandiant-maintained) parses the binary tracev3 plus uuidtext files into CSV. The macos-UnifiedLogs project from Mandiant is the canonical primary source for the file format documentation plus the parser implementation. Sarah Edwards mac4n6.com is the reference DFIR research body of work for forensic interpretation of unified log content.
What Investigators Actually Find
For incident response on macOS the unified logs are the primary source for several investigation questions. Process execution timeline: the log records every process spawn including command-line arguments plus parent process identifier. Network activity: the network framework writes entries for every TCP plus UDP connection including destination plus protocol metadata. SSH sessions: the ssh process writes structured log entries for every connection attempt, authentication outcome plus session close. AppleScript execution: scripts invoked through osascript leave log entries with the script content plus the calling process. Configuration changes: profiles, configuration daemons plus preference changes all emit structured log events.
The unified logs are particularly strong for investigations involving cross-process activity: any activity that crosses framework boundaries (LaunchServices, XPC, Notifications) leaves a trail through the relevant subsystem categories. For investigators tracing a sequence of activity across multiple processes the unified logs provide the correlation thread that ties the events together.
Retention Limits and the Acquisition Race
Unified log retention is configured per-process by the activity level plus the rate at which the source process emits events. The high-volume tracev3 files for active subsystems may roll over within hours. Lower-volume logs persist for several days. The default tracev3 rotation is approximately seven days but a busy system can rotate in under 24 hours. Persistent signpost data persists longer (weeks to months) plus is the source most likely to preserve evidence for older incidents.
The acquisition race is the practical limit: an investigation that opens days or weeks after the suspected incident may find that the relevant tracev3 entries have already rolled off. Sherlock Forensics engagements treat unified log acquisition as an early-triage priority specifically because of this race. Acquisition early in the engagement preserves the data; waiting until the formal investigation is scoped often loses the most relevant entries.
The macOS Forensic Posture in 2026
Cross-platform digital forensics work increasingly requires macOS literacy because macOS market share inside Canadian enterprise has grown materially across the last five years. Executive devices, developer workstations plus design workflows often run on macOS. Investigators who have only Windows-stack tooling miss the macOS surface entirely. Sherlock Forensics engagements include macOS unified log analysis as part of the standard incident response methodology plus our engagement page documents the cross-platform scope of our work.
For organizations supporting macOS endpoints in any quantity the operational discipline is to enable APFS snapshots on critical systems, document the unified log acquisition procedure as part of the incident response runbook plus practice the acquisition step before an actual incident forces the team to learn it under pressure.