One of the most contentious questions arising from yesterday’s critical examination of ChatGPT’s recommendations, is how long does the Unified log keep entries before they’re purged? ChatGPT seemed confident that some at least can be retained for more than a month, even as long as a year. Can they?

Traditional text logs are removed after a fixed period of time. One popular method is to archive the past day’s log in the early hours of each morning, as part of routine housekeeping. Those daily archives are then kept for several days before being deleted during housekeeping. That’s far too simple and restrictive for the Mac’s Unified log.

Apple’s logs, in macOS and all its devices, are stored in proprietary tracev3 files, sorted into three folders:

• Persist, containing the bulk of log entries, retained to keep their total size to about 525 MB in about 50-55 files;
• Special, including fault and error categories, whose entries are slowly purged over time until none remain in the oldest log files, so have a variable total size and number.
• Signpost, used for performance measurements, which also undergo slow purging until they vanish.

One simple way to estimate the period for which log entries are retained is to find the date of creation of the oldest log file in each of those folders. On a Mac mini M4 Pro run largely during the daytime, those dates were

• Persist, earliest date of creation 7 March 2026 at 16:54
• Special, 9 February 2026 at 19:41
• Signpost, 3 March 2026 at 16:41

when checked on 10 March. Those indicate a full log record is available for the previous 3 days, followed by a steady decline with age to the oldest entry 31 days ago. That compares with statistical data available in my app Logistician going back as far as 14 January, although all entries between then and 9 February have now been removed and lost.

Retrieving old log entries

The real test of how many log entries have been retained is to try to retrieve them. Although the oldest Special log file was created on 9 February, the oldest log entry I could retrieve was the start of the boot process on 11 February, in Special log files returning a total of over 44,000 entries for that day. However, no further log entries could be found after those until the morning of 24 February, a gap of over ten days.

This chart shows the numbers of log entries that could be found and read at intervals over previous days. Where a total of 500,000 is shown, that means over 500,000 for that 24 hour period. I checked these using two different methods of access, using the OSLog API in LogUI, and via the log show command in Ulbow. In all cases, log show returned slightly fewer than OSLog.

It’s clear that with only 3 days of full Persist log files, very few entries have been retained from earlier than 7 days ago, and beyond that retention numbers are erratic.

Over the period prior to the oldest Persist file, when entries could only be coming from Special log files, those included both regular and boundary types, and categories were diverse, including fault, error, notice and info, and weren’t confined to the first two of those categories. Most subsystems were represented, but very few entries were made by the kernel. There is thus no obvious pattern to the longer retention of entries in Special files.

Ephemeral entries

Log entries are initially written to memory, before logd writes most of them to permanent storage in tracev3 log files on disk.

The first substantial purging of entries thus occurs when logd decides which are ephemeral and won’t be retained on disk. This can be seen by following the number of entries in a short period of high activity in the log, over time, and is shown in the chart below for a sample period of 3 seconds.

When fetched from the log within a minute of the entries being written, a total of 22,783 entries were recovered. Five minutes later there were only 82% of those remaining. Attrition of entries then continued more slowly, leaving 80% after 8 hours. Analysis suggests that over this period in which there were about 6,100 log entries per second written to disk, approximately 1,700 log entries per second were only kept in memory and never written to disk. That suggests about 22% were ephemeral, a proportion that’s likely to vary according to the origin and nature of log entries.

Summary

• A fifth of log entries are likely to be ephemeral, and lost from the log within the first minutes after they’re written.
• Most retained log entries are written in Persist logs, where tracev3 files are removed by age to keep their total size to just over 500 MB. Those should preserve the bulk of log entries for hours or days after they’re written.
• Entries stored in Special log files may be retained for significantly longer, here up to a maximum of 29 days. Although those may contain fault and error categories, retention doesn’t follow an obvious pattern, making their period of retention impossible to predict.
• In practice, the period in which a fairly complete log record can be expected is that applied to Persist files, which varies according to the rate of writing log entries. In most cases now that’s unlikely to be longer than 5 days, and could be less than 12 hours.
• You can’t draw conclusions from the apparent absence of certain log entries from the log prior to the earliest entries in Persist log files, as it’s likely that those entries will have been removed.
• Expecting to retrieve log entries from earlier than 5 days ago is almost certain to fail.

In 1657, one of the great scientists of the Dutch Golden Age, Christian Huygens, invented the pendulum clock, the first timekeeping device accurate enough to make a second hand worthwhile, as it typically only lost about 15 seconds per day. It was another century before John Harrison developed his marine chronometer, a clock sufficiently accurate to enable precise determinations of longitude. Another hundred years later, with the coming of railways across Europe, ordinary people started synchronising clocks so they caught their train, and our ancestors soon became the first slaves to time.

I’m beginning to wonder whether Apple intends reversing that history. Have you not noticed something odd about setting times in more recent Mac apps, how few allow you to set the seconds? You can see what has happened over the last few years in my log browsers, Ulbow and LogUI.

Most of Ulbow’s interface was written using AppKit seven years ago, and it uses a standard Date Picker with elements containing the year, month, day, hour, minute and second. Given that you can get more than 10,000 log entries in a second, I would have preferred to offer decimal seconds, but that isn’t possible within the standard AppKit picker.

LogUI was written from the start using Apple’s more recent substitute for AppKit, SwiftUI, eighteen months ago. That doesn’t use the AppKit Date Picker, but has its shiny new DatePicker instead. Components available in macOS are there limited to year, month, day, hour and minute. To be able to include seconds your code must be written for an Apple Watch, as macOS, iOS and iPadOS don’t allow seconds at all. That’s why you have to enter them in a separate TextField, although that could perhaps allow the use of decimal seconds.

When I wanted to obtain higher resolution timestamps for log entries in LogUI, I discovered that standard date formatting in macOS only resolves to milliseconds (10^-3 second), and couldn’t stretch to microseconds (10^-6 second), let alone the nanoseconds (10^-9 second) that can be obtained from Mach absolute time, as used internally in parts of macOS. Even that reference has recently become lower resolution, as each ‘tick’ in Apple silicon Macs occurs every 41.67 nanoseconds, rather than once every nanosecond as in Intel Macs.

There’s another difference between Ulbow and LogUI with regard to timestamps that you’re less likely to be aware of: Ulbow obtains its log records indirectly using the log show command, which can include the Mach absolute time of each entry. Instead, LogUI accesses those entries direct through the more recent OSLog API, which doesn’t currently expose such precise times.

Lest this appear too far removed from the world of the user, look in the menu bar clock’s settings, and you’ll see Display the time with seconds is an option, but not the default. When the clock is shown on the Lock Screen or screensaver, it only displays hours and minutes, never seconds, neither can any of the digital clock widgets supplied with macOS. While the Clock app does support decimal seconds, that’s only permitted in its Stopwatch where hundredths are displayed, as they are on an Apple Watch and other devices.

This becomes stranger still when you consider the methods used to synchronise internal clocks. Since High Sierra, macOS has used its own timed service, which Apple describes as “synchronizing the clock with reference clocks via technologies like NTP”, that’s the Internet service provided by time.apple.com as in Date & Time settings. When accessed over the Internet, it’s generally accepted that NTP should be accurate to within tens of milliseconds, although that can at times worsen to 100 milliseconds or more.

As far as I’m aware, no Mac has ever had a GPS receiver built into it, but every iPhone apart from the earliest, and those iPads with cellular support, include assisted GPS and GLONASS. Those are capable of providing time accurate to about 100 and 200 nanoseconds respectively. Even my 11-year-old car corrects its clock using GPS.

Although our Macs and devices can share almost everything else now, my Macs appear unable to adjust their clocks to the more accurate time that should be available to my iPhone. But as iOS is so shy about displaying seconds anywhere, it makes me wonder whether iPhones make full use of GPS time, or mostly rely on that obtained from the nearest cellular mast.

I’m curious whether this is a deliberate campaign to abolish seconds wherever possible, or just the result of doing what looks sufficient. Maybe I’m a mere slave to time, and the Time Lords in Apple Park are on a mission to cure me by travelling back four centuries.

Over the last few weeks, I’ve been posed a series of questions that can only be resolved using the log, such as why Time Machine backups are failing to complete. The common confounding factor is that something has gone wrong at an unknown time, but if you don’t know exactly what you’re looking for, nor when to look, the Unified log is a hostile place, no matter which tool you use to browse its constant deluge of entries.

This is compounded by the fact that errors seldom come singly, but often propagate into tens of thousands of consequential log entries, and those not only make the cause harder to find, but can shorten the period covered by the log. In the worst case, by the time you get to look for them, the entries you needed to find are lost and gone forever.

In late 2017, I experimented with a log browser named Woodpile that approached the log differently, starting from a histogram of frequencies of log entries from different processes.

Viewed across the whole of a log file, this could draw attention to periods with frequent entries indicating potential problems.

The user could then zoom into finer detail before picking a time period to browse in full detail. Of course, at that time the Unified log was in its early days, and entries were considerably less frequent than they are now today.

A related feature in my later Ulbow log browser provides similar insights over the briefer periods covered, but like Woodpile that view seems little used, and isn’t offered in LogUI.

Another concern is that a great deal of importance can be recorded in the log, but the user is left in the dark unless they hunt for it. I documented that recently for Time Machine backups, and note from others that this isn’t unusual. Wouldn’t it be useful to have a utility that could monitor the log for signs of distress, significant errors or failure? To a degree, that’s what The Time Machine Mechanic (T2M2) sets out to do, only its scope is limited to Time Machine backups, and you have to run it manually.

Given the sheer volume and frequency of log entries, trying to monitor them continuously in real time would have a significant impact on a Mac, even if this were to be run as a background process on the E cores of an Apple silicon Mac. In times of distress, when this would be most critical, the rate of log entries can rise to thousands per second, and any real-time monitor would be competing for resources just when they were most needed for other purposes.

A better plan, less likely to affect either the user or the many background services in macOS, would be to survey log events in the background relatively infrequently, then to look more deeply at periods of concern, should they have arisen over that time. The log already gives access to analysis, either through the log statistics command, or in the logdata.statistics files stored alongside the folders containing the log’s tracev3 files. Those were used by Woodpile to derive its top-level overviews.

Those logdata.statistics files are provided in two different formats, plain text and JSON (as JSON lines, or jsonl). Text files are retained for a shorter period, such as the last four days, but JSON data are more extensive and might go back a couple of weeks. I don’t recall whether JSON was provided eight years ago when I was developing Woodpile, but that app parses the current text format.

Keeping an eye on the log in this way overlaps little with Activity Monitor or other utilities that can tell you which processes are most active and using most memory, but nothing about why they are, unless you run a spindump. Those also only show current figures, or (at additional resource cost) a few seconds into the past. Reaching further back, several hours perhaps, would require substantial data storage. For log entries, that’s already built into macOS.

I can already see someone at the back holding up a sign saying AI, and I’m sure that one day LLMs may have a role to play in interpreting the log. But before anyone starts training their favourite model on their Mac Studio M3 Ultras with terabytes of log entries, there’s a lot of basic work to be done. It’s also worth bearing in mind Claude’s recent performance when trying to make sense of log entries.

What do you think?