7 min read
If you work with sensitive sources on a Mac, you probably carry a quiet assumption: if something happens to my laptop, the logs will tell us what. It's a reasonable belief. Every modern operating system records a stream of what runs, what connects to the network, and what touches which files.
For most people, that assumption is fine. For journalists, human rights researchers, and anyone whose device is a plausible target, it quietly fails — and it fails in a way that only becomes obvious after it's too late to fix. macOS keeps far less log history than almost anyone expects, and the way you collect those logs changes how much survives by an order of magnitude.
Since macOS Sierra, Apple has used a system called Unified Logging. Instead of the plain-text log files you might remember from older Unix systems, macOS writes highly compressed, proprietary tracev3 files into /var/db/diagnostics. This is a genuinely capable system that captures an enormous amount of detail about what the machine is doing.
The catch is in how it decides what to keep. Traditional logging retains entries for a fixed period — say, 30 days — and then rotates them out. Unified Logging does the opposite: it retains entries to stay within a size budget, not a time window. The bulk of activity lands in what Apple calls the "Persist" store, which is trimmed to hold roughly 525 MB of data across about 50 rolling files.
On a laptop that runs all day, every day — which describes most working reporters' machines — that size budget fills fast. In practice, a busy Mac often retains only somewhere between twelve hours and about five days of history before the oldest entries are permanently deleted to make room for new ones. Independent testing by the Eclectic Light Company found that expecting to retrieve log entries from more than five days ago is "almost certain to fail." A smaller category of fault and error records can linger longer, but unpredictably — you cannot rely on it.
There is no user setting to make the log keep more. The size limit is fixed by the system, and the more active the machine, the shorter the window.
For a normal user, short log retention is harmless. For a team that handles confidential sources and leaked documents, it's a structural gap in your ability to answer the most important question after a suspected compromise: what actually happened, and what did it touch?
Consider the realistic timeline. A reporter notices something odd — a strange configuration profile, an unexpected permission prompt, a battery that drains too fast. They mention it to a colleague. A few days pass. Eventually someone with technical skills sits down to look. By then, on an always-on Mac, the log entries covering the original event may already be gone. Not hidden, not encrypted — overwritten and unrecoverable.
This is the same pressure we describe in incident response tabletops, where the story is two days from publication and a device is behaving strangely. The difference is that logging attrition doesn't wait for your investigation to begin. The clock starts the moment something happens, and it runs whether or not anyone is watching.
Suppose you do catch a problem in time and want to preserve what the machine remembers. There is a right way and a wrong way, and the difference is dramatic.
The instinct many people have is to run a Sysdiagnose — the diagnostic bundle Apple support asks for — or simply to reboot and "start clean." Both are mistakes. A reboot can flush in-memory entries that were never written to disk, and Sysdiagnose captures a surprisingly thin slice of the log.
Instead, if you need to preserve evidence, capture a full log archive from the command line before doing anything else:
log collect --output evidence.logarchive
You can then examine the archive on a separate machine with a filter, for example:
log show evidence.logarchive --predicate 'eventMessage contains "tccd"'
How much does the method matter? In side-by-side forensic testing, a log collect archive retained roughly a 30-day span and about 26 million events, while the Sysdiagnose version of the same device held about two days and 7.9 million events. Same machine, same logs — three to four times more evidence, purely from how it was collected.
That's a genuinely useful thing to know, and a technical staffer can run it today. But notice what it is: point-in-time preservation. It only helps if you already know an incident happened and you act inside the retention window.
The uncomfortable truth is that most compromises of high-risk users are not caught in the moment. They're suspected later, confirmed later still, and often surfaced by an outside party — a security researcher, a platform threat notification, a tip from another target. By the time anyone thinks to run log collect, the window that mattered has usually closed.
A single manual capture also assumes the machine is still in your hands, still powered on, and hasn't been running long enough to churn through its log budget. For a device that may have been compromised weeks ago, none of those assumptions hold.
The only reliable answer to log attrition is to stop depending on the device to remember. Telemetry has to be captured continuously and moved off the machine — into storage that isn't bound by macOS's local size budget — while it's still fresh. That is a fundamentally different posture from "we'll grab the logs if something looks wrong."
Continuous capture is necessary, but it isn't sufficient on its own. Getting real answers after an incident depends on three things working together:
These map directly onto what a managed detection and response baseline is for. The value isn't a specific product name — every macOS security tool ultimately draws from the same set of system events Apple exposes. The value is that the telemetry is captured before it decays, watched by someone accountable for it, and turned into evidence you can rely on when it counts. That's the difference between hoping the logs will be there and knowing they will.
Organizational monitoring is the durable fix, but there are worthwhile steps any individual can take on their own Mac right now. These reduce your exposure — they don't replace centralized visibility, and they sit alongside it rather than instead of it:
Relying on Macs for sensitive work?
The question isn't whether your laptops are logging — it's whether anyone will still have the evidence when it matters. If your team works from Macs, we can help you get continuous coverage that outlasts the device's own memory.