What's Keeping Your Mac Awake? 4,588 Assertions, 0 Sleeps

Every guide to a Mac that will not sleep ends at the same command: run pmset -g assertions and read the list. I run a Mac mini as a 24/7 agent server, so I ran it expecting a tidy answer. What I got instead was a summary table that has no row for a fifth of the events in my own power log, a top offender that never appears in the table at all, and a sleep-blocking assertion held by a Bluetooth trackpad that is not connected to anything.

So I stopped reading the summary and parsed the log. Below is what seven days of power management bookkeeping actually looks like on one machine, and why the command everyone recommends is the wrong place to start.

The machine, and what it never did

Mac16,10 — an M4 Mac mini, 16 GB, running headless, with idle sleep off across the board:

$ pmset -g custom
AC Power:
 sleep                0
 displaysleep         0
 disksleep            0
 standby              0
 powernap             1
 womp                 1

I pulled pmset -g log, which covered 2026-08-09 18:17:01 to 2026-08-16 18:06:43 — about seven days, 4,665 lines. The log states its own headline result plainly:

Sleep/Wakes since boot at 2026-08-10 18:38:33 +0900 :0   Dark Wake Count in this sleep cycle:0

Zero sleeps. Uptime at the time of reading was 5 days, 23:28. That matters for what follows: this machine spent the whole week generating 4,588 parsed assertion events about a sleep transition that never happened. The accounting runs whether or not it is load-bearing.

Broken down by what the event was:

Action	Events
Released	3,664
Created	383
Summary	364
ClientDied	174
TimedOut	3

Releases outnumber creations 9.6 to 1. That ratio is the first sign that the log is not a balanced ledger, and it turns out to have a single cause.

70.3% of the events come from a process the summary never shows

Grouping the same 4,588 events by owning process:

Process	Events	Share
coreaudiod	3,224	70.3%
nfcd	400	8.7%
powerd	374	8.2%
storagekitd	124	2.7%
WindowServer	120	2.6%
caffeinate	81	1.8%
bluetoothd	74	1.6%

The audio daemon owns seven of every ten power assertion events on a headless server with nothing playing. Then the sharper detail: every one of coreaudiod's 3,224 events is a Released. Not one Created. It releases assertions in pairs — 1,612 PreventUserIdleSystemSleep and 1,612 PreventUserIdleDisplaySleep, named like com.apple.audio.context1065.preventuseridlesleep — whose creation the log never recorded.

This is not specific to my box. A MacRumors thread from 2025-04-29 reports the identical shape on a Mac Studio M4 running macOS 15.3: "every few minutes, 24/7, the pmset log gets spammed by coreaudiod", all of them Released PreventUserIdleSystemSleep. The advice in that thread is to run pmset -g assertions to find the culprit, and on my machine that command lists coreaudiod nowhere, because by the time you look it has released everything again.

The mechanism shows up in a bug report with actual code attached. mpv issue #11617 (opened 2023-04-23) found that mpv correctly released its own io.mpv.video_playing_back assertion when paused, but coreaudiod held onto com.apple.audio.BuiltInSpeakerDevice.context.preventuseridlesleep — an assertion coreaudiod had created on another process's behalf. The naming pattern matches mine exactly. So the process listed as the owner is frequently a proxy, and the application actually responsible does not appear in the output at all.

Three views of the same system, and none of them agree

The status table printed by pmset -g assertions has nine rows, and my seven-day log contains eleven distinct assertion types. They are not the same eleven.

Four types that fired during the week — SystemIsActive, InternalPreventSleep, DisplayWake, NoIdleSleepAssertion — have no row in the summary table. That is 657 events, 14.3% of the total, invisible to the recommended command. Two rows that the table always prints, SoftwareUpdateTask and ExternalMedia, never occurred at all.

The third column is the one I did not expect. I grepped the shipped SDK header for CFSTR definitions of each type string. Of the thirteen types involved, five are publicly defined in MacOSX26.5.sdk/.../pwr_mgt/IOPMLib.h:

IOPMLib.h:292  #define kIOPMAssertPreventUserIdleSystemSleep  CFSTR("PreventUserIdleSystemSleep")
IOPMLib.h:380  #define kIOPMAssertNetworkClientActive         CFSTR("NetworkClientActive")
IOPMLib.h:1023 #define kIOPMAssertionTypePreventSystemSleep   CFSTR("PreventSystemSleep")
IOPMLib.h:1030 #define kIOPMAssertionTypeNoIdleSleep          CFSTR("NoIdleSleepAssertion")

The other six — SystemIsActive, UserIsActive, InternalPreventSleep, BackgroundTask, DisplayWake, ApplePushServiceTask — appear nowhere in the IOKit headers. They account for 916 events, 20.0% of the week. You can watch them, you cannot look up what they mean, and you cannot create one yourself. UserIsActive is in that group, which becomes a problem in the next section, because it is what is holding this server awake right now.

A disconnected trackpad has been asserting user activity for 52 hours

Here is the live output, three assertions held:

$ pmset -g assertions        # 2026-08-16 18:06:43
pid 350(powerd):       143:27:16 PreventUserIdleSystemSleep "Powerd - Prevent sleep while display is on"
pid 350(powerd):       143:27:16 UserIsActive               "com.apple.powerd.ws.initialize"
pid 409(WindowServer):  52:23:17 UserIsActive               "com.apple.iohideventsystem.queue.tickle
    serviceID:100015e56 service:AppleMultitouchDevice product:sicei's Trackpad eventType:11"

143:27:16 is 5.98 days, which matches uptime exactly — powerd has held that assertion continuously since boot. Note what its name says: sleep is prevented because a display is on. I run this machine with a dummy display attached, so the setting I thought was doing the work (sleep 0) is not the only thing doing it. pmset -g prints both layers on one line: sleep 0 (sleep prevented by powerd).

The third one is stranger. A Magic Trackpad tickled the HID event system, WindowServer raised UserIsActive, and 52 hours later it is still up. Meanwhile:

$ system_profiler SPBluetoothDataType | grep -E "^ {6}(Connected|Not Connected):"
13:      Not Connected:

There is no Connected: section. All three Bluetooth devices — a Magic Mouse, a keyboard, and that trackpad — are disconnected. The assertion outlived the connection. For anyone chasing a Mac that will not idle, this is the failure mode that will waste an afternoon: the thing marking you present is a peripheral that left.

One more caveat I could not resolve. That assertion's creation event is not in the log. Searching seven days for its serviceID:100015e56 returns only the trailing live dump. The only two Created events for a WindowServer UserIsActive both name Magic Trackpad rather than sicei's Trackpad, and both land immediately after a powerd restart. The live view and the log are describing different assertions, and I do not know why — log store rotation is a guess, not a finding.

What I read now

The man page is careful in a way the tutorials are not. man pmset says -g assertionslog "shows a log of assertion creations and releases", and on this machine the creations for 70% of events are simply absent. So the order that works:

1. Read the Listed by owning process block, never the status table above it. The table drops four real types and invents two that never fire.
2. Treat the named string as the evidence, not the process. com.apple.audio.context1065... tells you an audio client exists; coreaudiod is only the proxy holding it.
3. Poll it. A process that grabs and drops an assertion every few minutes is invisible in any single snapshot, which is exactly how coreaudiod hides.
4. Check ClientDied in the log. I logged 174 of them, 124 from storagekitd holding com.apple.diskmanagementd. Those are assertions released because the owner died, not because it cleaned up.

Two footnotes worth keeping. caffeinate accounts for 81 events here and none of them are mine — grepping ops/ and ~/Library/LaunchAgents/ for the word returns nothing but a prose mention in an old research note. And man caffeinate is dated November 9, 2012, with a SYNOPSIS reading [-disu] while the options list below it documents a -m flag that the synopsis omits. The tooling around this subsystem has been stable for well over a decade, documentation gaps included.

I have changed nothing. This machine still never sleeps, which is what I want from a box that draws a few watts and runs jobs around the clock. The reason to read the assertion log anyway is that the same bookkeeping decides whether your StartCalendarInterval jobs fire on time on a machine that does sleep, and a stuck assertion fails the same silent way a launchd job that dies without a signal does.

Sources and method: all counts come from one machine — a Mac16,10 Mac mini, M4, 16 GB — parsing 4,665 lines of pmset -g log spanning 2026-08-09 18:17:01 to 2026-08-16 18:06:43 with a regex that matched 4,588 assertion events; 45 further Assertions lines had empty name fields and were excluded, so the type counts are a floor. Header claims were checked by grepping CFSTR definitions in MacOSX26.5.sdk; man page text is quoted verbatim from man pmset and man caffeinate on this machine. Two limits are worth stating plainly: idle sleep is disabled here, so I measured assertion accounting and not which assertion would have blocked a real sleep; and the mismatch between the live 52-hour assertion and the log has no confirmed cause. I did not establish why coreaudiod cycles audio contexts on a headless server, and the nfcd figure is reported as-is — ioreg -rc AppleNFC returns zero lines, but device-tree nodes named nfc,primary,spmi and nfc,primary,gpio do exist, so I am not claiming the hardware is absent. One machine, seven days, one OS build; do not generalize to your Mac without running the same commands on it.