How to Use Console.app for Diagnosing Problems on macOS

Console.app exposes macOS’s unified logging system — an enormous, continuous stream of log messages from every process and subsystem, which is exactly why filtering effectively, not just opening Console and scrolling, is the actual skill involved.

Step 1: open Console

Applications → Utilities → Console

Step 2: select the right log source

Sidebar → your Mac's name (live logs) vs.
          "Crash Reports" / "Log Reports" (historical)

Live logs under your Mac’s name show activity as it happens; Crash Reports specifically collects application crash logs, which is usually the faster starting point when diagnosing a specific app crash rather than an ongoing behavior.

Step 3: filter by process name first

Search field → type the app or process name

This alone cuts an overwhelming, unfiltered stream down to just the entries from the specific application or system process you actually care about.

Step 4: use the search field’s structured filters for more precision

process:mdworker
subsystem:com.apple.bluetooth

Console’s search supports structured predicates beyond plain text — filtering by exact process name or subsystem identifier, rather than a substring match that might catch unrelated entries.

Step 5: reproduce the problem while watching the filtered live stream

Start streaming (Console does this automatically for live
sources), then trigger the actual problem, watching for new
entries appearing in real time.

Watching logs update as the problem happens, rather than searching after the fact, makes it much easier to correlate a specific log entry with the specific action that triggered it.

Step 6: check a specific application’s crash report in detail

Crash Reports sidebar → select the specific crash →
  read the crash type and the top frames of the stack trace

Even without deep debugging expertise, the crash type (a null pointer dereference vs. an out-of-memory kill, for instance) and which library/framework appears in the top stack frames often points at whether the problem is in the app itself or a system framework it depends on.

Step 7: export relevant logs for sharing with support or a developer

Select the relevant entries → File → Export...
              (or Save, for a Crash Report)

Exporting a targeted, already-filtered log excerpt is far more useful to a developer or support contact than telling them to “check Console” themselves.

Step 8: use log show from Terminal for scripted/repeatable queries

log show --predicate 'process == "mdworker"' --last 1h

The same unified logging system Console displays is also queryable directly from the command line — useful for a query you want to repeat exactly, or to pipe into another tool.

Why filtering by process/subsystem first is the entire skill

Unfiltered, Console’s live stream is thousands of lines of activity from dozens of unrelated processes every minute — genuinely unusable for diagnosing anything specific without narrowing it down first. Learning to filter by the specific process or subsystem actually relevant to your problem, before trying to read anything, is what turns Console from overwhelming noise into a genuinely useful diagnostic tool.