Guide
What is keeping your Mac awake?
Your Mac will not sleep, the fans are up, and nothing obvious is running. macOS is not being mysterious: something has told it to stay awake, that something has a name and a process id, and you can ask. This guide shows you how to find it, how to read the answer, and how to check what happened while you were not watching. At the end there is a note on the opposite problem — a Mac that sleeps through work you wanted finished — which is what Perked exists for.
Nothing keeps a Mac awake anonymously
macOS decides whether it can sleep by looking at a list of power assertions. An assertion is a request from a running process that says "not yet" — and every one of them carries the process that made it, the kind of sleep it blocks, and usually a human-readable reason.
That is the important part: there is no such thing as an anonymous wake-lock. If your Mac is awake when it should not be, some process is on record asking for it, and two commands will show you which.
PreventUserIdleSystemSleep— the Mac will not fall asleep on its own. This is what a long job or a download holds.PreventUserIdleDisplaySleep— the screen stays on too. Video players and presentation apps take this one.PreventSystemSleep— blocks sleep even harder, including some cases where you closed the lid.UserIsActive— you touched the trackpad or a key recently. It expires by itself; it is not a stuck process.
Ask the system: pmset -g assertions
Open Terminal and run pmset -g assertions. The top block is a system-wide tally — a 1 next to PreventUserIdleSystemSleep means something is holding sleep off right now. The block underneath is the one you actually want, because it lists the assertions by owning process:
- pid 23164(Perked) the process id and its name — this is your culprit, or your innocent bystander.
- 01:45:21 how long that assertion has been held. A number that keeps climbing is a process that never let go.
- named: "…" the reason the process gave. Well-behaved apps write something readable here, like "Powerd - Prevent sleep while display is on".
- Timeout will fire in 285 secs this one expires by itself. Assertions without a timeout are held until the process releases them — or exits.
If a name means nothing to you, run ps -p <pid> with the number from that line to see the full command behind it. And if the process is one you can simply quit, quitting it releases the assertion immediately — there is nothing else to clean up.
When the list comes back empty
A common frustration: the Mac clearly refused to sleep last night, and this morning pmset -g assertions shows nothing at all. That is not a bug — assertions are live state. Whatever held one has since finished or been killed, and the evidence went with it.
There is also a second cause that assertions never explain: your Mac was not held awake, it was woken up. Network traffic, a Bluetooth device, a scheduled task, a USB device or a power adapter being plugged in can all pull it out of sleep. For both of those, you need the history rather than the current state.
The command that answers "what woke it at 3am"
pmset -g log is the part most guides skip, and it is the only one that works after the fact. It keeps a running history of every sleep, wake and assertion change, with the reason attached. Ask it what woke the machine:
pmset -g log | grep -i "Wake from"— every wake, with the hardware or software reason. "due to UserActivity Assertion" is you; "due to en0" is the network; a USB device names itself.pmset -g log | grep -i assertion— the assertion history, so you can see which process took one at 02:58 and never gave it back.pmset -g log | grep -i "Entering Sleep"— when it did manage to sleep, and what it thought the reason was.
Read it from the timestamp you care about, not from the top. The log covers days, so the answer to "why was my battery at 4% this morning" is usually a single line somewhere around the time you went to bed.
The graphical version: Activity Monitor
If you would rather not use Terminal, Activity Monitor has an Energy tab with a "Preventing Sleep" column — sort by it and the offending app is at the top. It is quicker to reach and it is enough for the common case of one obvious app.
It only shows applications, though, and it only shows now. Background daemons, command-line tools and anything that already exited will not appear, which is why the pmset commands above remain the thorough answer.
The usual suspects
- caffeinate the built-in command that exists to hold an assertion. Perfectly normal — unless you started one in a terminal window you have since forgotten about.
- A left-over pmset disablesleep run pmset -g | grep SleepDisabled. If it says 1, sleep is switched off system-wide and it survives reboots. Undo it with sudo pmset -a disablesleep 0.
- Backups and indexing Time Machine and Spotlight (mds, mds_stores) take assertions while they work. These finish on their own; let them.
- Docker, VMs and containers a running VM or container runtime usually keeps the machine up for as long as it is running, whether or not it is busy.
- Downloads, uploads and sharing browsers, cloud sync clients and screen sharing all assert while a transfer or session is live.
- An external display or a dock plugging in can change the power profile entirely, and some docks hold a USB kernel assertion of their own.
The opposite problem: it sleeps when you need it awake
Most people who look this up eventually find the reverse: the Mac slept, and it took a long job with it. An AI coding agent, a build, a render, an overnight script — all of them die quietly when the machine idles out, and none of them hold an assertion of their own.
The blunt fixes have real costs. caffeinate keeps everything awake until you remember to stop it. sudo pmset -a disablesleep 1 turns sleep off system-wide, needs an admin password, and stays off across reboots until you undo it — which is how people end up here in the first place.
Perked is the scoped version of the same idea: it watches for coding agents and any process you nominate, holds the assertion only while they actually run, and drops it the moment they finish. It stays power-aware while it does — AC-only or above a battery threshold you set — and pauses when the Mac gets too hot. Everything it does shows up in pmset -g assertions under its own name, exactly like the entries above, so you can always check its work.
Frequently asked
What is a power assertion on macOS?
A request from a running process asking macOS not to sleep. Each one records the process that made it, which kind of sleep it blocks, and usually a readable reason. Nothing can hold your Mac awake without appearing in that list.
How do I see what is keeping my Mac awake right now?
Run pmset -g assertions in Terminal and read the "Listed by owning process" block — it names the process id, the assertion type, how long it has been held and the reason given. Activity Monitor’s Energy tab shows the same thing for applications, under "Preventing Sleep".
pmset -g assertions is empty but my Mac still would not sleep. Why?
Because assertions are live state: whatever held one has since exited. Use pmset -g log instead — it keeps the history, so you can look at the exact time it happened and see which process asserted, or what woke the machine.
How do I find out what woke my Mac up?
Run pmset -g log | grep -i "Wake from". Each line gives a timestamp and a reason: user activity, a network packet on en0, a USB device, or a scheduled maintenance wake. Those are wakes, not assertions, which is why they never show up in pmset -g assertions.
I ran pmset disablesleep 1 and now my Mac never sleeps. How do I undo it?
Run sudo pmset -a disablesleep 0, then confirm with pmset -g | grep SleepDisabled — it should read 0. That setting is system-wide and survives reboots, so it will not clear itself.
Can I keep my Mac awake only while a specific job runs?
Yes. caffeinate -w <pid> holds an assertion until that process exits, and caffeinate -i <command> holds one for the length of a command you run through it. Perked does the same thing automatically for AI coding agents and any process you add, with battery and thermal limits on top.
Stop guessing which process to blame
Perked keeps your Mac awake only while your agents are actually running, and writes down every decision. One-time €1.
Related guides
The command behind most of this: the macOS caffeinate command, flag by flag →
Running long jobs unattended? Run AI coding agents overnight on a Mac →
Need the lid shut? Keep your MacBook awake with the lid closed →