The Death of the Console App
For decades, if a Mac application crashed or a piece of hardware failed, systems administrators opened the graphical “Console” application to read the system logs. The Console app displayed plain-text files that anyone could read. However, starting in macOS Sierra, Apple completely redesigned the logging infrastructure.
Modern macOS logs are no longer plain-text files. They are compressed, encrypted, and mathematically structured binary databases. The graphical Console app is now mostly useless for deep historical analysis, often freezing when trying to load massive datasets.
If you are an IT professional trying to figure out exactly why a MacBook rebooted itself at 4:00 AM on a Tuesday, you cannot rely on graphical tools. To query, filter, and extract diagnostic data directly from the unified logging system, you must use the incredibly powerful log command.
Step 1: Open the Terminal
Because you are extracting potentially sensitive diagnostic data (including network activity and application errors) directly from the core of the operating system, you should always run these commands with root administrator privileges.
- Press Command + Space to open Spotlight Search.
- Type
Terminaland press Enter.
Step 2: The Raw Data Dump (The Firehose)
The most basic way to use the log command is to ask the operating system to show you everything that is happening in real-time. You use the stream argument.
sudo log stream
The moment you press Enter, the terminal will violently explode with text. macOS generates thousands of background log entries every single second. The screen will scroll so fast it is impossible to read. This is known as “drinking from the firehose.” To stop the endless stream of data, press Ctrl + C.
Streaming the entire system is useless. You must filter the data.
Step 3: Filtering the Stream by Process
If you are trying to figure out why the Safari web browser is crashing, you do not care about the logs generated by the Bluetooth module or the Wi-Fi card. You only want to see logs generated by Safari.
You can use the --predicate flag to apply a strict mathematical filter to the stream. You force the command to only display logs where the process name matches exactly what you want.
sudo log stream --predicate 'process == "Safari"'
Now, the terminal will sit perfectly silent. It will only output a line of text if Safari actively generates an error or a diagnostic message. You can open Safari, force it to crash, and watch the exact error code appear in the terminal in real-time.
Step 4: Searching Historical Data
Real-time streaming is great for testing, but what if you need to know what happened yesterday? You cannot use the stream argument because the event has already occurred. You must use the show argument to search the historical database.
If a user complains that their Mac randomly rebooted yesterday, you can search the historical logs for the word “reboot” or “shutdown.” However, searching millions of logs takes time. You should restrict the search to a specific timeframe using the --last flag.
sudo log show --predicate 'eventMessage CONTAINS "shutdown"' --last 24h
This command tells macOS: “Search the database, but only look at the last 24 hours. Find every single log entry that contains the word ‘shutdown’ and print it to the screen.”
Step 5: Exporting Data for Engineers
If you find the exact log entry that caused the crash, but the error code is too complex for you to understand, you need to send it to a senior software engineer.
You can force the log command to output the data not as terminal text, but as a fully formatted system file (a .logarchive) that an engineer can open on their own computer.
sudo log collect --last 24h --output /Users/Shared/crash_data.logarchive
This command perfectly packages the last 24 hours of system activity into a highly compressed, shareable diagnostic file. By mastering the log command, you bypass the limitations of graphical utilities and gain absolute access to the diagnostic brain of the Mac.