One of the most common reasons for looking in the log is when an error occurs and isn’t reported sufficiently. It’s also probably the most common reason for frustration with the log, when you can’t identify the error you were looking for. This article explains why the log may not be a good place to identify the cause of errors.

Claude conned

Perhaps the best illustration of the difficulties faced by those using the log to investigate errors is in Claude’s attempt to diagnose problems with the Clock app.

First, it came across what it classed as a memory allocation error in the entry
00.968273 error com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] Memorystatus failed with unexpected error: Invalid argument (22)

Then it found and misinterpreted a cryptic entry from the kernel that also referred to memory
10.891949 kernel Clock[19237] triggered unnest of range 0x1e8000000->0x1ea000000 of DYLD shared region in VM map 0x5c946da0d472dbbf. While not abnormal for debuggers, this increases system memory footprint until the target exits.

It continued by misreading perfectly normal sequences of entries made by RunningBoard and FrontBoard, involving jargon such as assertion, as pathological cycles. Like someone who had skimmed quickly through a complex detective novel, Claude then jumped to the wrong conclusions.

Riddled with errors

Perfectly normal logs are full of errors, the great majority being expected or benign, and surprisingly few turn out to be reflected in what actually occurs. To demonstrate this, I took a log extract with a total of 25,159 entries excluding Signposts and found that 820 of them contained the word error in their message. So you can expect around 3% of all log entries to mention errors.

This is reversed when you look for entries classed as Error or Fault, which are usually rare and seldom contain information relevant to a problem you’re investigating. This is because many significant abnormal conditions and events are reported in entries that aren’t classified as Error or Fault, and often don’t include the word error in the message.

Process killed

The real error that Claude didn’t find (possibly because it wasn’t included in the submitted log extract) occurred when a key process, mobiletimerd, exceeded its memory allowance, so was killed. The diagnostic sequence of log entries for that ran:
03.099138 kernel process mobiletimerd [19118] crossed memory high watermark (15 MB); EXC_RESOURCE
03.099148 kernel memorystatus: mobiletimerd [19118] exceeded mem limit: InactiveHard 15 MB (fatal)
03.100180 kernel mobiletimerd[19118] Corpse allowed 1 of 5
03.100567 kernel 54578.846 memorystatus: killing_specific_process pid 19118 [mobiletimerd] (per-process-limit 0 0s rf:- type:daemon) 15360KB - memorystatus_available_pages: 1327431
03.100665 com.apple.opendirectoryd PID: 19118, Client: 'mobiletimerd', exited with 0 session(s), 0 node(s) and 0 active request(s)
03.100679 gui/501/com.apple.mobiletimerd [19118] exited with exit reason (namespace: 1 code: 0x7) - JETSAM_REASON_MEMORY_PERPROCESSLIMIT, ran for 110ms
03.100708 gui/501 [100015] service inactive: com.apple.mobiletimerd

To the knowledgeable human, that reads clearly, but doesn’t include general terms like error, so could well be lost on AI.

Process failed

This example should be more readily accessible in the log, but could be overlooked. This occurred when a Spotlight service tried to extract content from a text file that started with certain characters such as LG, resulting in an indexing failure:
30.946740 mdwrite Decoding error: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=[private]} for [private]
30.951004 mds Decoding error: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=[private]} for [private]

Error code 4864 is NSCoderReadCorruptError, implying that the presence of characters at the start of a text file may be triggering a bug in RichText.mdimporter, the importer module shipped in macOS that’s responsible for indexing plain text files.

Process halted

My third and final example comes from an examination of why Safari was failing to load and display a webarchive, and illustrates how macOS privacy and security features can halt a process that would otherwise complete successfully.

For Safari to load the main frame, it needed to obtain PolicyForNavigationAction approval. What happened is:
01.154639 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::decidePolicyForNavigationAction: listener called: frameID=24, isMainFrame=1, navigationID=26, policyAction=0, safeBrowsingWarning=0, isAppBoundDomain=0, wasNavigationIntercepted=0
01.154642 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::receivedNavigationActionPolicyDecision: frameID=24, isMainFrame=1, navigationID=26, policyAction=0
01.154666 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::isQuarantinedAndNotUserApproved: failed to initialize quarantine file with path.
01.154666 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::receivedNavigationActionPolicyDecision: file cannot be opened because it is from an unidentified developer.
01.154799 Error Safari Safari Web view (pid: 596) did fail provisional navigation (Error Domain=NSURLErrorDomain Code=-999 "(null)")

What should have happened instead is that the decision was approval:
00.740168 com.apple.WebKit 0xa4bda0718 - [pageProxyID=19, webPageID=20, PID=1035] WebPageProxy::decidePolicyForNavigationAction: listener called: frameID=4294967298, isMainFrame=1, navigationID=25, policyAction=Use, isAppBoundDomain=0, wasNavigationIntercepted=0
00.740172 com.apple.WebKit 0xa4bda0718 - [pageProxyID=19, webPageID=20, PID=1035] WebPageProxy::receivedNavigationActionPolicyDecision: frameID=4294967298, isMainFrame=1, navigationID=25, policyAction=Use
00.740233 com.apple.WebKit 0xa4bda0718 - [pageProxyID=19, webPageID=20, PID=1035] WebPageProxy::receivedNavigationActionPolicyDecision: Swapping in non-persistent websiteDataStore for web archive.

Although reported in an entry classed as Error for once, its consequences aren’t made clear in subsequent log entries.

Error reporting in macOS

When Apple replaced traditional logs with the Unified log in macOS Sierra, it made it clear that the new log wasn’t intended for advanced users or system administrators, but primarily for engineers. However, no provision was made for significant errors to be reported in any more accessible form. None of my three examples were reported directly to the user, who was left unaware of what had happened, and why.

This failure to report errors to users has only led to more bugs being ill-defined and unreported, and has done Mac users a great disservice by eroding confidence.

Strategy

Identifying the cause of an error using the log has similarities with solving a ‘whodunnit’ detective novel. There’s usually no shortage of suspects and clues, although many of those may prove misleading. Tracing a suspect’s whereabouts can often prove decisive in determining whether they were in the right place at the right time, and sometimes establishing how the crime happened is essential to its solution.

One big difference from detective fiction is being able to establish what is normal, and drawing comparison between a normal record of what should happen for comparison against an abnormal extract can be valuable.

Suggestions:

• Obtain a complete log record, without the use of predicates, saved either as a logarchive or a LogUI JSON file. Although you’ll find it easier to work with filtered versions, only a complete record has all the entries you might need.
• When possible, compare a ‘normal’ sequence of events with the abnormal record.
• Identify and trace subsystems and processes specific to the malfunctioning component(s).
• Identify and trace subsystems and processes with controlling roles, including LaunchServices, RunningBoard, TCC and security.
• Process IDs can be invaluable when tracing.
• Turn detective.

AI future

The Unified log might appear an ideal opportunity for AI approaches, but the reality is that we’re still a long way from achieving reliable interpretation by AI.

One severe limitation that’s often overlooked is that current techniques don’t fare well at the scale required. Analysing even a modest log extract involves well over 250,000 tokens, comparable to assessments made by NovelQA. Whereas human performance with those models exceeds 90%, few AI systems can attain more than 70%, and in some cases fail to reach even 50%.

Maybe one day, but for the moment at least humans are likely to remain best at using the log to identify the cause of errors.

Spotlight local search problems are common, and are all too often tackled blindly by forcing a volume’s indexes to be rebuilt. Although that can sometimes resolve the problem, without knowing its cause, it can just waste time and effort. In some cases rebuilding the indexes can worsen the problem, at least temporarily. This article explains how to use SpotTest and other tools to perform systematic testing and arrive at a diagnosis before hazarding a guess at its treatment.

1. Setting up

Before going any further, check that Spotlight settings are in order, and don’t exclude the volume or folder you’re trying to search, or the document type you’re looking for. In Spotlight settings,

• check all Results from System are turned on, particularly Files and Folders,
• click on Search Privacy… and remove any locations you want to include in search.

Then open Activity Monitor and watch its CPU % listing to verify that Spotlight isn’t currently in the process of reindexing or performing other maintenance to its indexes. If it is, delay testing until those have completed. Searching using Spotlight while it’s actively working on its indexes will give odd results, or none at all.

If you’re going to use SpotTest on any location with privacy control, such as your Home Documents folder or an external disk, add the app to the Full Disk Access list in Privacy & Security settings, before opening it.

2. Home folder test

Even if your interest is in a different volume, perform a basic test of a new test folder in your current Home folder, to establish a baseline and confirm that Spotlight is working there.

Open SpotTest and set it to defaults, with a Term of cattle, a Scope of [Home], and both Search Keywords and Search EXIF ticked.

Click the Create Tests tool (the leftmost of the tools) to create the folder of test files at the top level of your Home folder. Make a note of the time to the second that you do this.

About 10 seconds after that, click either the Run NSMetadata test or Run mdfind test tool. You should then see a list of files found, including those in the test folder ~/0_SpotTestFiles, including A, B, C, D, E, F, G, K, L, M.

If you don’t see those listed, open Mints and use the Log Window button in its Spotlight section to obtain a log extract from the time the test files were created, or use LogUI to do the same. You’ll then need to look at that log extract to see if there are clues as to why indexing didn’t take place in that period.

Leave the test folder where it is, and anything from 1 hour to 5 days later, repeat the search using either or both of those tools. Once additional indexing has been undertaken:

• NSMetadata should now find A, B, C, D, E, F, G, I, K, L, M but not H
• mdfind should now find A, B, C, D, E, F, G, H, I, K, L, M.

I is found using Live Text, and H by Visual Look Up, the latter only being found by the mdfind search.

These tests have demonstrated:

• mdworker and mds indexing of files supported by system mdimporters;
• delayed background mediaanalysisd image analysis and mds indexing of Live Text and Visual Look Up content.

To match test files with their importers, click the Check importers tool. Note that file L doesn’t use a plugin, and N uses a plugin but can’t be found because the search term is inside an image in the PDF document, which currently isn’t recoverable content.

3. Metadata indexing

If that test isn’t fully successful, or you’re uncertain whether indexing is complete, inspect the metadata of the test files. Open a Finder window on the contents of ~/0_SpotTestFiles, set it to Column View, and widen the window to provide a suitable Preview pane within it. Select each of three files in turn and confirm their metadata are shown correctly. To inspect all available metadata, click on any Show More text.

SpotTestC.pdf will have different datestamps, but the seven fields of metadata below those should be identical to those shown above.

SpotTestK.jpg will also have different datestamps, but the five fields below should be identical to those above.

SpotTestM.txt should include a final line of Keywords one, cattle, three.

You can also check all indexed metadata for those files in Terminal using the commands
mdls ~/0_SpotTestFiles/SpotTestC.pdf
mdls ~/0_SpotTestFiles/SpotTestK.jpg
mdls ~/0_SpotTestFiles/SpotTestM.txt

Missing metadata on those three files demonstrates that the test folder hasn’t been indexed correctly. You can try restarting your Mac, leaving it a few minutes to update its Spotlight indexes, then repeating the tests using SpotTest.

4. Custom mdimporter

Many apps come with their own custom mdimporter that provides Spotlight indexing support for document types not supported by macOS. In the past, these were normally installed in /Library/Spotlight, but more recent apps typically keep them inside the app bundle in Library/Spotlight. These can be tested easily.

Create and save one of those custom document types, so that it contains the word cattle in a way that should be searchable by Spotlight. Copy that document to the ~/0_SpotTestFiles folder, wait about 10 seconds, then repeat the test search. You may well notice that NSMetadata search doesn’t find your custom test document, but mdfind does, because of the difference in the search criteria they use.

You should also click the Check importers tool to check that the correct mdimporter was recognised and used for the custom document type.

5. Volume test

If Spotlight works correctly with the test folder in your Home folder, you may wish to progress to testing a different volume or location. Having created its test folder in ~/0_SpotTestFiles, copy that to the other location. Before you change the Scope of the search, click on the button to list available volumes, then select the volume containing the copied test folder in the Scope menu.

When you perform the two types of search on that volume, the same rules should apply as to which will be found. Note though that finding files I and H can take much longer, or they may not appear at all.

6. Search term test

When you’re confident that a search term of cattle can be found reliably, you may wish to extend your testing to other terms. Take care when choosing custom terms, as you want to be confident that they should be found, but not in such numbers that the results are overwhelming. You will also need to create your own test files containing the custom term.

Diagnosis

SpotTest can thus provide key information on:

• Delay or absence of find following creation of test files. If no indexing activity is seen in the log, that indicates indexing failure. If the test files are indexed promptly, it indicates search failure.
• Delay or absence in finding files H and I, indicating an indexing failure.
• Failure of a custom mdimporter to index a custom document type.
• Failure to index another volume.

Those should fit in with the overall scheme used by Spotlight, as shown below.

Happy hunting!

Diagnosing problems using the Unified log is a complicated business that requires understanding, insight, experience and a systematic approach. As few of us feel competent to wade through thousands of log entries trying to spot where things go wrong, this might seem an ideal opportunity for the use of AI. I’m very grateful to one of our regular readers for the opportunity to demonstrate how Claude coped with diagnosing a troublesome problem they’ve been having with the Clock app in Tahoe.

Signs and symptoms

When you’re diagnosing any problem, you should start with a clear account of its signs and symptoms before even thinking of resorting to the log. A good physician may take an hour or more obtaining a full history and examining a patient before they start thinking about performing any special investigations. Even though signs and symptoms may not lead you to a diagnosis, they should help you direct your investigations to best effect.

In this case, although the Clock app is launching, when displaying some views the content is missing. We therefore agreed to capture the log from the moment of launch from the Finder until one of the problematic views displayed. That’s easy to achieve by double-clicking the app when the menu bar clock has just turned to display 00 seconds, then checking the time again when the view has been displayed. Add a couple of seconds to the latter to determine the period to view in LogUI.

What’s normal?

Recognising what’s abnormal in the log is only possible if you know what the normal looks like. It’s often perfectly normal to see error messages, but knowing which are relevant is more difficult. In this case, I cheated and obtained a matching log extract from launching the Clock app on another Mac running the same version of Tahoe, making it simple to compare the two.

An interesting exercise for the reader is to submit a perfectly normal log extract to AI, with a vague description like “problems starting the app”, and seeing if it reports that as being normal. I doubt that it would.

Preparing a log extract for submission to AI

LogUI can provide log extracts saved to Rich Text Format, preserving the entry fields, although I doubt whether any AI will be able to interpret those correctly. Perhaps the best route is to save the extract in RTF, and save that in turn as plain text. A longer way round is to:

• Save the whole extract as a JSON file, to preserve the whole record.
• Use the Search tool to display the entries you want to submit for analysis.
• Click on the Reduce tool to remove the unwanted entries.
• Save the remaining entries in Rich Text, then save that in plain text format.

That also allows you to submit a shorter extract.

Claude’s report

AIs like Claude are thoroughly professional in their reporting, even when they’re utterly incorrect. In this case, Claude’s report is headed Complete Analysis of the Problem, and appears a confident and detailed assessment presented logically. It first establishes:

• The App DOES Launch Successfully
• Main Issue: Continuous Assertion Invalidation
• Infinite State Loop
• Critical Errors Identified

supporting those with digested “quotations” from the log, although in fact most of them are rendered in Claude’s words, not those in the log entries themselves.

It then leaps on to give the Final Diagnosis that the Clock app:

• Launches
• Creates its scenes and interfaces
• Registers functionalities (alarm, stopwatch, timer)
• Fails to maintain the assertions necessary to remain active
• The system continuously invalidates its resource requests.

Those are embellished with appropriate and emoji.

Following those conclusions, it cites what it terms Key Log Evidence in support of that diagnosis. Among those are the following.

Critical Error at Launch

For this, it quotes part of the message from
00.968273 error com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] Memorystatus failed with unexpected error: Invalid argument (22)
and a similar entry.

However, it doesn’t point out that those are rapidly followed by
00.969966 com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] set Memory Limits to Soft Inactive (800)
00.970684 com.apple.launchservices LAUNCH: Successful launched 0x0-0x3b03b pid=1921 com.apple.clock '[private]'
which would appear to contradict this being a “critical error”.

Kernel Warning

Claude’s report next misquotes one of the log entries as reporting
Clock[19237] triggered unmask of range (1 of 16384:0000->0x1ce000000 of DVLD shared region in VM map 0x5c946dd8d4c72dbbf
when in fact the full entry reads
10.891949 kernel Clock[19237] triggered unnest of range 0x1e8000000->0x1ea000000 of DYLD shared region in VM map 0x5c946da0d472dbbf. While not abnormal for debuggers, this increases system memory footprint until the target exits.
It gives no reason for changing unnest to unmask, DYLD (which makes sense) to DVLD (which is nonsense), or changing the range given.

For interest, I used LogUI’s Gloss feature to submit that entry to ChatGPT for its explanation:
This log entry is a system notice from the kernel indicating that a portion of the DYLD shared region in the virtual memory (VM) map has been unnested. […] In short: The macOS kernel is reporting that the process Clock caused a part of the shared dynamic library cache to become private memory. This is expected behaviour when certain debugging or memory operations occur, but it will temporarily use more RAM until the process exits.

Continuous Assertion Cycle and Scene Management Loop

Claude then claims that the perfectly normal entries made by RunningBoard and FrontBoard demonstrate a continuous assertion cycle and scene management loop. Anyone who has read my account of RunningBoard would realise that is a misreading of what is both common and normal.

Claude’s Possible Solutions

Nearing the end of the report, Claude recommends four possible solutions:

• Reset system permissions: sudo tccutil reset All com.apple.clock
• Rebuild launch services cache: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
• Verify system integrity: sudo /usr/libexec/repair_packages --verify --standard-pkgs
• If everything fails: This could be a specific bug in macOS Tahoe with the Clock app that requires a system update.

The first is misleading, as TCC has nothing to do with system permissions, but privacy controls. Although Claude has made no comments at all on entries by TCC, I have checked through those thoroughly and there’s no evidence of any problem with that subsystem. The command recommended isn’t likely to do anything useful, either.

Despite Claude having provided no evidence of any problem with LaunchServices, its second solution is to perform a full reset of the LaunchServices registry (not cache), although I’m not sure the command given is correct for that. This used to be a popular panacea in the past, but is now more trouble than it’s likely to be worth. The last time I reviewed this for Sequoia, I wrote:
“Running either of those in recent versions of macOS including Sequoia is likely to wreak havoc, though. While this appears to be effective with the Open With… list, its effects on System Settings can be catastrophic. This can remove its entire contents, and even blow the wallpaper away. Normal function should start to return after restarting the Mac, but even then problems can persist.”

Yet Claude gives no warnings of any adverse effects.

The third solution given is the most puzzling. repair_packages was used to repair System permissions in versions of macOS up to El Capitan. It hasn’t been used since, makes no sense at all in Tahoe with SIP and the SSV, and that command no longer exists anyway. I find it surprising that Claude should be recommending a course of action from ten years ago.

The final recommendation is manifestly ineffective, as this problem has persisted across updates from 26.0 to 26.0.1 and now 26.1.

Nowhere does Claude recommend the obvious course of action to contact Apple Support.

Claude’s Summary

The slick summary rounding off Claude’s Complete Analysis of the Problem states confidently that its root cause “appears to be either:”

1. “A system-level bug in macOS Tahoe’s memory status handling for this specific app”
2. “Corruption in the app’s entitlements or sandbox configuration”
3. “A conflict between the app’s resource requirements and what the system is willing to grant”

with the parting comment:
The error code 22 (EINVAL – Invalid argument) in the memorystatus call suggests the app is requesting memory limits or priority settings that the kernel considers invalid for its configuration.

None of those comments is supported in reality, nor by the evidence in the log extract.

My final test was to compare the log entries that Claude singled out as being diagnostic of the problem it has ‘completely analysed’, with those from my Mac mini M4 Pro, whose Clock app works perfectly. You won’t be surprised to learn that, in those respects at least, the two logs are identical. For the avoidance of doubt, that includes the “Kernel Warning” and “Critical Error at Launch” entries that Claude considered diagnostic.

My Summary

When presented with a log extract, Claude misidentified and misread log entries, and introduced errors in reporting what it claimed were the most important diagnostic entries. Its recommended solutions were ineffective, unwise, or a decade out of date. Neither did it give any warnings for their adverse effects, or recommend contacting Apple Support.

This doesn’t say that AI can’t help interpret macOS Unified log entries, and can’t do better in the future. But I hope it demonstrates the reality of what it will do today.

Postscript

Following up on Claude’s suggested solutions, I can confirm that the suggested tccutil command is ineffective, and that Tahoe has removed the -kill option from lsregister “because it was dangerous and no longer useful”. As the third solution was removed years ago, that leaves only the last of its suggestions that is valid.

Following the introduction of the Unified Log, a surprising number of folk you would expect to use it have stopped. Some experienced developers and those providing advice in Apple Support Communities seemingly take pride in their lack of log literacy, claiming that the log is now impossible to use, and only accessible to Apple’s engineers. While it does present obstacles, pretending that the log isn’t a vital tool in diagnosis and understanding is burying your head in the sand. This article shows why.

Why the log?

The log provides support for several purposes. It’s widely used to investigate events such as bugs and unexpected behaviours, to establish their cause before working out how to fix them, in diagnosis and troubleshooting. It’s also used to discover how subsystems within macOS work, and what they do. Examples of those include LaunchServices, DAS-CTS scheduling and dispatching, and RunningBoard, all of which are nearly invisible to other methods, but write copious and explicit entries in the log. With its precise time recording and special Signpost log entries, it’s also invaluable for measuring performance, hence in optimising code.

Concentrating on the log’s use in diagnosis, log entries can be used to answer most of the key questions:

• What happened?
• When did it happen?
• Who made it happen?
• How did it happen?
• Why did it happen?
• What can I do about it?

Diagnose a mystery update

To illustrate those in practice, I’ll use an example that happens to be fresh in my mind, the silent updating of XProtect data last week. The only two clues available outside the log were the fact that XProtect had been updated, and that had occurred at 06:46:43 GMT on the morning of 17 September. There was no record of this event anywhere else that might have given any better information on how it had occurred.

Browsing the log from one second earlier confirmed what and when that had happened. I quickly discovered who made it happen when I found the log entry
2025-09-17 06:46:42.615072 com.apple.duetactivityscheduler REQUESTING START: 0:com.apple.security.syspolicy.xprotect-update:7874AD
revealing that update had been accomplished by a background check scheduled and dispatched by DAS-CTS, and performed by an update service com.apple.security.syspolicy.xprotect-update.

That in turn fired up XProtectUpdateService, which recorded that it promptly completed and activated the update:
2025-09-17 06:46:42.695517 com.apple.xprotect Connecting to XProtectUpdateService
2025-09-17 06:46:42.744182 com.apple.security.XProtectFramework.XProtectUpdateService XProtectUpdateService booting
2025-09-17 06:46:43.157255 com.apple.security.XProtectFramework.XProtectUpdateService Attempting to apply update: [private]
2025-09-17 06:46:43.191178 com.apple.security.XProtectFramework.XProtectUpdateService Update completed. Activated update [private]

XProtectUpdateService initiated a connection to the iCloud service now used to update XProtect in Sequoia and later, but log entries didn’t show the update being downloaded from that source. Instead, there was an error reported in the entry
2025-09-17 06:46:43.193159 com.apple.syspolicy.activities Finished Xprotect update in 496.4100122451782 ms: Error Domain=XProtectUpdateError Code=2 "Activated update LocalUpdate[5315]" UserInfo={NSLocalizedDescription=Activated update LocalUpdate[5315]}

Although the messages in many of these log entries are opaque, that entry makes it clear that XProtectUpdateService hadn’t downloaded the new version from iCloud, but had activated a local update, which we know from experience means the copy already downloaded to the traditional XProtect location had been used to install that update in its new location. That used to be available to the user through the xprotect update command, but is no longer. Thus, the only way that update could have been installed was the result of com.apple.security.syspolicy.xprotect-update being run routinely.

If we can’t intervene and force the update manually, the final piece of information we need is how often com.apple.security.syspolicy.xprotect-update is run, and that’s revealed into a later log entry:
2025-09-17 06:46:43.202474 com.apple.duetactivityscheduler Submitted: 0:com.apple.security.syspolicy.xprotect-update:58B6CE at priority 5 with interval 86400 (Wed Sep 17 22:58:51 2025 - Thu Sep 18 18:58:51 2025)
i.e. every 86,400 seconds, or 24 hours.

Procedure

How difficult was that to discover? Even with minimal prior knowledge, consummately easy, and it only took a couple of minutes.

My starting point was the timestamp reported for the update by xprotect version, of 06:46:43 GMT. I therefore set LogUI to display 5 seconds of log starting from one second before that. In the screenshots below, times are shown in BST, one hour in advance of GMT.

This returned a total of 7,174 log entries, far too many to browse. Knowing that I was looking for entries concerning XProtect, I then typed that into the search box and pressed Return, to display only those entries whose message contained the text xprotect.

That narrowed down the number of entries to just 65, starting with the scoring and dispatch of com.apple.security.syspolicy.xprotect-update by DAS-CTS at 42.608967 seconds, and containing all the entries quoted above. Just to be certain that I hadn’t missed anything relevant, I then cleared the search box and pressed Return to display all log entries again, scrolled down to 42.608967 seconds, and checked through those for the period to 43.19315 seconds, when the update had completed.

Of course, not all log investigations are as simple or successful, but many are just as straightforward. The main limitation isn’t the excessive number of log entries, but those from subsystems that make very few entries, as occurs in Spotlight indexing and search. There’s always a way to filter out unwanted entries, but you can’t magic in entries that were never made in the first place.

Conclusions

Browsing the log might appear daunting, even overwhelming or terrifying at first, but as you become more familiar with it you appreciate the rich information it can provide. Log literacy is one of the basic skills required for anyone who wants or needs to dig deeper into their Mac or Apple device. Without it diagnosis, research and performance measurement are like trying to paint a landscape while wearing a blindfold.