Read the assertion snapshot
The local pmset manual says processes can dynamically override power-management settings by using I/O Kit power assertions, and that pmset can list those processes and assertions. Apple’s energy-efficiency guidance also points developers to pmset -g assertions when checking whether their processes are preventing sleep. Run it while the symptom is happening, then preserve the time and relevant owning-process lines.
Look for categories such as preventing idle system sleep or preventing display sleep, but do not assume an entry is malicious. A backup, video export, network operation, or other user-requested task may legitimately hold an assertion for a while. Repeat the snapshot after that work is expected to finish.
pmset -g assertionsTurn an observation into a diagnosis
Compare the assertion output with Activity Monitor, pmset -g log, the Mac’s sharing and network-access settings, and any connected device. Apple specifically recommends checking those areas when sleep is unexpected. If one third-party app consistently holds an assertion while idle, update it or contact its developer with a trimmed log and the steps that reproduce the problem.
Do not kill a system daemon or disable services just because they appear in the output. That may disrupt a valid task and does not explain why it ran. If no assertion appears, continue checking schedules and wake history instead of concluding that no sleep-related issue exists.
pmset -g log
pmset -g schedWattGuard reports the finished session
WattGuard records completed sleep blockers with the rest of a sleep session, so you can compare an affected night with earlier sessions. It groups process families and estimates impact from available activity signals. It does not alter assertions, promise a blocker is the cause of a wake, or replace an app developer’s diagnosis.