Old thread, but it’s one of the top results for usernoted CPU problems and it ended without a resolution, so I wanted to share how this played out for me — including the exact log command that finally named the culprit, since @MpuPer got stuck at exactly the “I have logs but can’t interpret them” stage.
My case (July 2026, macOS 26): usernoted pinned at 97–99% CPU continuously, Mac heating up. Same behavior Per saw — killall usernoted respawned it pinned again within 2 seconds, and rebooting changed nothing.
What was actually happening. Sampling the process showed why it was spinning:
sample $(pgrep -x usernoted) 3
The hot stack was an infinite loop in -[UNCalendarNotificationTrigger nextTriggerDateAfterDate:] → Calendar.nextDate(after:matching:) → Calendar.dateAfterMatchingWeekOfYear — the daemon endlessly computing the next fire date for a scheduled repeating notification whose date components could never resolve.
Finding which app. The usual internet advice is to wipe the notification databases, but on modern macOS the store is TCC-protected, the old db2 file is a 0-byte decoy, and a blind wipe doesn’t even tell you which app caused it. The decisive diagnostic was:
/usr/bin/log show --predicate 'process == "usernoted"' --info --last 5m
One gotcha worth knowing, since it nearly derailed me: use the full path /usr/bin/log. In zsh there’s a builtin named log that shadows it and fails with “too many arguments” — very easy to misread as “no logs found.” That may be relevant to why the log route felt like a dead end here.
In my output, the culprit appeared dozens of times per second: Timelines (time-tracking app, com.glimsoft.Timelines) redelivering two repeating “re-engagement” notifications with authorizationStatus: Denied. I had denied the app notification permission, but its scheduled repeating requests stayed in the store — so usernoted looped forever computing fire dates for notifications it was never allowed to deliver. So @jcoates’s instinct in this thread was right: it was one specific app, and the DND/DEVONthink entries were probably just noise around the real offender.
The fix: deleting the app dropped usernoted from a sustained 99% to 0% instantly. No reboot, no database wipe, no other apps’ notifications lost.
Verifying it’s really fixed (Activity Monitor’s %CPU column misleads right after a restart of the process):
PID=$(pgrep -x usernoted); T1=$(ps -o time= -p $PID); sleep 10; ps -o time= -p $PID
If the CPU-time delta over those 10 seconds is near zero, it’s genuinely idle.
If anyone lands here with the same symptom: run the /usr/bin/log show command above, look for one bundle ID repeating relentlessly (especially with authorizationStatus: Denied on repeating notifications), and deal with that app — before reaching for the database-wipe advice.
