Query unified logs narrowly

The unified logging system stores structured events viewed through Console or the log command. Every process on the Mac writes into it, which is both the strength and the trap: everything is there, and an unfiltered query drowns you in it.

The discipline: begin with the failure time and one process or subsystem. You know roughly when the problem happened. Anchor every query to that window.

Filter by process and time

log show --last 10m --style compact \
  --predicate 'process == "ExampleApp"'

The compact style prints one event per line: timestamp, event type, then process[pid:thread] and the message. Scan the timestamps around the failure moment and read the messages near it.

Predicates compose, so you can tighten further:

log show --last 10m --style compact \
  --predicate 'subsystem == "com.example.sync" AND eventMessage CONTAINS[c] "timeout"'

subsystem and category are the labels developers give their own log lines, and eventMessage CONTAINS[c] does a case-insensitive text match. Those four keys — process, subsystem, category, eventMessage — cover most troubleshooting queries.

Watch live instead of digging

When you can reproduce the problem on demand, stream instead:

log stream --predicate 'process == "ExampleApp"'

Start the stream, trigger the failure, and read what appears at that instant. This beats archaeology every time the bug is reproducible.

Scope and privacy

Expand the time window only when evidence requires it. --last 10m returns in seconds; --last 24h without a predicate can take minutes and produce gigabytes of noise that hides the signal.

Logs can include private paths and user data, while some values are deliberately redacted. You will see <private> where an app chose not to expose a value — that is by design, not corruption. And treat exported logs as sensitive: they can reveal filenames, server names, and account hints, so scrub them before attaching to a public bug report.