Mac won't go to sleep on its own

After this, the Mac sleeps within the normal idle timeout again instead of running all night.

Why this happens

Sleep on macOS is cooperative, and Apple's power management framework (IOKit/IOPMLib) actually defines several distinct assertion types, not just one. PreventUserIdleSystemSleep is the one that matters most — it stops the whole machine from idling to sleep, though the display can still dim and lid-close or a low-battery shutdown still work. PreventUserIdleDisplaySleep only keeps the screen on and doesn't touch system sleep at all — useful to tell apart, since an app holding only that one isn't your culprit here. There's also PreventDiskIdle and NetworkClientActive, which exist for different reasons entirely.

Beyond the obvious video-call or download case, a wide range of ordinary apps are routinely reported holding one of these open longer than expected: Zoom (which can also leave a ZoomAudioDevice.driver virtual audio device running after you quit it), Adobe Creative Cloud's sync helper while it's indexing, Dropbox/OneDrive/Google Drive during a large sync, BitTorrent clients like Transmission (which has an explicit "prevent sleep during transfers" setting), screen-sharing sessions held open by sharingd, and even coreaudiod itself when a Bluetooth or AirPlay audio session doesn't release cleanly. None of this is officially documented by Apple as a bug list — it's what shows up repeatedly across user reports — but it's exactly the kind of process pmset -g assertions below will name directly, so you don't have to guess which of these it is. A Mac that's also showing high kernel_task usage at the same time as refusing to sleep usually has the same process behind both.

Fix it

1. Check the GUI first: Activity Monitor → Energy tab has a Preventing Sleep column — sort by it and anything showing "Yes" is a candidate. This is enough to spot an obvious offender without touching Terminal. For the full picture with assertion names attached, the terminal read is more precise:

   ● Reads the system

   What it does: prints every active power assertion, grouped by the process holding it.

   After: nothing changes, this only reads.

   pmset -g assertions

   Copy

   Output

   Listed by owning process:
      pid 74715(Google Chrome): [...] NoIdleSleepAssertion named: "WebRTC has active PeerConnections"
      pid 2835(Safari): [...] PreventUserIdleDisplaySleep named: "com.apple.WebCore: HTMLMediaElement playback"
      pid 91370(caffeinate): [...] PreventUserIdleSystemSleep named: "caffeinate command-line tool"
           Details: caffeinate asserting for 300 secs

   Captured live on the verification machine. That last line is the single most common real-world cause: a caffeinate command left running in a Terminal tab, sometimes started by another tool (like a long brew install or a screen-sharing session) that calls it internally and doesn't always clean up after itself.

2. If the owner is a browser tab or app doing something you started on purpose (a call, a download, a backup), just let it finish or quit it from its own interface — that's the normal path and releases the assertion immediately. If the owner is a leftover caffeinate process you don't need anymore, end it directly:

   ▲ Changes running state

   What it does: terminates every running caffeinate process for your user.

   After: the assertions it held are released immediately; the Mac can sleep again on its normal timeout.

   killall caffeinate

   Copy

   Revert: nothing to restore — if you needed it to keep the Mac awake, just run caffeinate again.

3. If the Mac is sleeping fine but keeps waking up on its own instead, that's a different question — what woke it, not what's holding it. The full sleep/wake/assertion history since boot is available directly:

   ● Reads the system

   What it does: prints the sleep/wake/assertion log since boot.

   After: nothing changes, this only reads. Output is long — pipe it to grep -i wake or open it in a text editor.

   pmset -g log

   Copy

   Output (excerpt)

   2026-09-07 01:12:04 +0400 Assertions   PID 608(runningboardd) Summary PreventUserIdleSystemSleep  00:01:12
   2026-09-07 01:12:19 +0400 Assertions   PID 608(runningboardd) Released PreventUserIdleSystemSleep  00:01:26
   Total Sleep/Wakes since boot: 618

   Captured live on the verification machine — trimmed for width; real lines are longer. Every assertion create/release is timestamped and attributed to a PID, which is the fastest way to catch a short-lived assertion that's already gone by the time you run pmset -g assertions. Skip any older guide that tells you to grep for a specific "Wake Reason: RTC/LID0" code — that exact wording has changed across macOS versions; grep for Wake or Sleep instead and read the surrounding lines.

Still broken?

• kernel_task is also using unusually high CPU
• An external monitor stopped being detected after the Mac slept or woke

Verified on

The assertion list above was captured live on the M3 / macOS 26.6 row.

Related problems

• kernel_task pegging the CPU on its own
• External monitor not detected after sleep/wake
• Battery draining fast while the Mac is actually awake