How do you use the Apple unified log for incident response?

To use the Apple unified log for incident response on a Mac, preserve first and analyze second. Run log collect to save a .logarchive, then query that copy with log show and predicates for process, subsystem and time range. Avoid working only on the live system, because logs age out.

What is the unified log?

macOS, iOS and the other Apple platforms write system and app messages to one logging system. The log command-line tool reads those messages, which apps produce with os_log and os_trace. The manual page says some commands need root privileges, and that is true of collecting a full archive.

Messages are not written to plain text files you can grep. They live in a binary store, so you read them through the tool. That is why the first step is to export a copy you can analyze later.

How do you preserve evidence?

The log collect command writes the system logs to a .logarchive that you can open later with the log tool or the Console app. Per the manual page, you can limit what is captured with options such as a start time, a duration with the last option, or a size. If you give no output path, it creates system_logs.logarchive in the current directory.

sudo log collect --last 2d --output ./case-4127.logarchive

Choose the window by what you know. If a user reports odd behavior from yesterday afternoon, go back farther than that. The manual notes that a predicate can raise the time and memory needed to build an archive, so collect broadly, then filter when you read.

The manual page also documents a directory option that reads a log store from another location, useful for a system partition that is not booted, such as one from a recovery environment or an external drive. Treat that as a way to examine a disk you have attached, not the machine you are logged into, where you want to avoid changing evidence.

How do you query the archive?

Point log show at the archive and filter with a predicate. The manual page gives examples that filter by subsystem, by category, or by a sender's image path. A typical start:

log show case-4127.logarchive --start "2026-10-17 13:00:00" --end "2026-10-17 17:00:00" --predicate 'process == "sudo"' --info

Useful predicate fields from the manual include process, subsystem, category, senderImagePath and eventMessage. Combine them with and, or and contains. Start narrow with one process or subsystem, read what you get, and widen.

The manual also lists output styles: default, compact, json, ndjson and syslog. Use ndjson or json when you want to load results into another tool for filtering, and compact when you are reading by eye.

What should you look for?

Constructed example. A laptop user reports a pop-up asking for a password, then nothing. You collect an archive, then query for authorization and process launch messages in the 20 minutes around the report. You find a short-lived process you do not recognize launched by a script, followed by a credential prompt from a system service. That gives you a process name and a time to pivot on in endpoint and network logs.

Typical things to read for: new process launches around the reported time, privilege escalation prompts, changes by system configuration services, and messages from the network and security subsystems. What exists depends on what the system and apps chose to log, so absence of a message is not proof that nothing happened.

What are the limits?

• The store is not kept forever. The manual lists a time-to-live option under log erase, so speed matters.
• What gets saved depends on persistence settings. The manual describes a persist mode with off, default, info and debug levels, set through log config, which needs root.
• Collecting on the live host changes the host. Note your own commands and times in the case record.

How to check or apply this

1. Decide whether you need the live machine or can isolate it. Record who ran what and when.
2. Run log collect with a generous window and a clear output name, and store the archive off the machine.
3. Hash the archive and note the hash in the case notes.
4. Query with log show by process, subsystem and time, using ndjson when you need to filter further.
5. Build a timeline of events, then confirm with other sources such as endpoint tools and network logs.
6. Practice this on a spare Mac before you need it.

Quick check

Sources

• macOS manual page log(1), read locally on macOS 27.0 with the man command

Last reviewed: 18 October 2026.