your Mac writes down why it wakes up

what the log says when your Mac wakes up

three commands answer three different questions. run all three before changing a single setting: together they take under a minute and replace the whole guessing list.

1. pmset -g log | grep -i "wake from" — every wake macOS recorded, oldest first, newest at the bottom.
2. pmset -g sched — anything that has asked to wake the Mac at a specific time.
3. pmset -g — the settings actually in force right now, including whether anything is holding sleep off.

the reason comes after «due to», not in the brackets

a wake line has a fixed shape, and knowing which part is which is the whole trick. this one came off the Mac this page was written on, with its tabs squeezed to spaces:

2026-09-08 03:39:10 +0300 DarkWake DarkWake from Deep Idle [CDNPB] : due to NUB.SPMI0Sw3IRQ nub-spmi0.0x02 nub-spmi-a0.0x25 rtc/Maintenance Using AC (Charge:79%)

the second column says whether this was a dark wake or a full one. the bracketed [CDNPB] is a flag code for the sleep state it came out of, not the reason — plenty of advice reads it as the reason and gets the diagnosis backwards. everything after «due to» is the cause. the tail is power source, charge and, on short wakes, how long it stayed up.

ioreg answers «what happened just now»

the log is a history. for the latest event alone, ioreg -rc IOPMrootDomain prints Wake Reason, Wake Type, Last Sleep Reason and Last Sleep Options as plain fields. here the first two held «NUB.SPMI0Sw3IRQ nub-spmi0.0x02 nub-spmi-a0.0x25 rtc» and «UserActivity Assertion» — the raw string and the label macOS put on it, side by side. that pairing is the fastest way to learn what a token means: let the Mac translate one for you.

the same idea — reading a number macOS already keeps instead of guessing at the symptom — applies to the other panic of Mac diagnostics: what memory pressure actually measures

Apple's own page on the symptom, and the one that points at pmset in the first place: Apple Support — if your Mac sleeps or wakes unexpectedly

dark wake at night is normal and not what is bothering you

macOS wakes in two ways. a full wake lights the screen and starts the fans; a dark wake keeps the display off, runs a short piece of work — mail, a Time Machine snapshot, an update check — and goes back down. dark wakes happen many times a night by design, on every Mac, and all of them are in the log.

the proportion is what to look at before panicking. eight days of log here hold 46 wake events: 37 dark, 9 full. of the nine, five say «HID Activity» and one «pwrbtn» — a person touching the machine, which is not a fault. the dark thirty-seven are what the advice lists tell you to eliminate, and they were never the problem. kill the mechanism behind them and you have made the Mac worse at maintenance without touching the peripheral that actually woke you.

the fan is the other half of this: a dark wake that runs long enough to spin it is following the length of the work, not its size: why your Mac fan is loud

the reasons that actually wake a Mac up at night

these are the strings that came out of the log, not a list of what can theoretically appear in one. the counts are from those same eight days.

• smc.sysState.Wake(…) wifibt … E_RX_IP_PACKET ARPT/ — 26 of 46, by a distance the most common. a packet arrived on Wi-Fi and the wireless chip judged it worth waking for. this is «wake for network access» doing its job.
• NUB.SPMI0Sw3IRQ … rtc/Maintenance, and the same with rtc/SleepService — 7 of 46. the real-time clock fired because macOS booked the slot in advance. rtc/ always means «scheduled», and pmset -g sched shows by whom.
• HID Activity — 5 of 46, all full wakes. a key, the trackpad, a mouse. a keyboard under a bag counts, and so does a lid that is not quite shut.
• UserActivity Assertion — 3 of 46 alone, twice more alongside another reason. software asserted a person is present. assertions are usually discussed as what keeps a Mac awake; they also wake one.
• E_TKO_NO_RESPONSE ARPT/ — 2 of 46. the TCP keep-alive offload stopped getting answers and handed the connection back to the CPU. it exists only because tcpkeepalive is on.
• smc.sysState.Wake(…) pwrbtn — the power button, once.

if you are on Apple silicon, half the guides are for a different machine

EC.LidOpen, EC.PowerButton and the rest of the EC.* family came from the embedded controller in Intel Macs. across 46 wake events on this Apple silicon Mac not one EC. string appears — the log talks in smc.sysState.Wake, NUB.SPMI, rtc and HID Activity instead. if you are searching for a token and finding nothing, check which architecture the page you are reading was written on.

what the Intel-era wake reasons looked like, in a reader's own words: Apple Community — wake reason EC.LidOpen in Terminal

the peripherals are named, just not in the log

«a device woke it» never appears as a wake reason with a product name in it. it appears one command over: the bottom of pmset -g assertions carries a Kernel Assertions block listing every peripheral armed to wake the machine, by the name printed on the box.

here the header reads Kernel Assertions: 0x124=USB,THNDR,MAGICWAKE, and under it sit a RODECaster Pro II, a Razer Basilisk V3, a USB Storage device and a stack of hubs at 0x4=USB, a Thunderbolt dock at 0x20=THNDR, and en0 at 0x100=MAGICWAKE. that is the suspect list, written out. unplug from it rather than from memory.

womp and tcpkeepalive still exist, and they split by power source

System Settings shows «wake for network access» as one switch. pmset -g custom shows what it is: womp, set separately for battery and for AC. here womp reads 0 on battery and 1 on the mains — which is why a Mac can be quiet all night unplugged and restless in a dock, with nothing in the interface to explain it. tcpkeepalive sits next to it, on, and produces the E_TKO_ lines above. both keys are alive in macOS 26.6.2, and ioreg lists WakeOnMagicPacket under Supported Features.

waking is one thing, and coming back wrong is another — if the Mac wakes fine but the network does not: reconnect a vpn that drops after sleep

the scheduled ones tell you who booked them

people skip pmset -g sched because they expect «backup» or «software update». what it prints is the internal name of whatever set the timer. two live entries here: com.apple.alarm.user-invisible-com.apple.calaccessd.travelEngine.periodicRefreshTimer and com.apple.alarm.user-invisible-com.apple.osanalytics.hardhighengagementtimer — Calendar refreshing travel times, and analytics. user-invisible means no interface offers to turn it off, which saves you an evening hunting the checkbox.

the wake that ends with the Mac putting itself back to sleep

check this one if the Mac has ever come out of a bag warm. the Last Sleep Options entry in ioreg -rc IOPMrootDomain held {"Sleep Reason"="Dark Wake Thermal Emergency"} here, and the log carries the matching line: Entering Sleep state due to 'Dark Wake Thermal Emergency':TCPKeepAlive=active. that is a dark wake cut short by a heat limit — the Mac woke to do maintenance in an enclosed space, could not shed the heat, and forced itself back down. not a fault, nothing to switch off, but it tells you the machine is being asked to work in a bag.

if that reason turns up more than once, the temperature behind it is readable too: check cpu temperature on Apple silicon

the long-form version of this diagnosis, with more log territory than pmset covers: The Eclectic Light Company — why does my Mac keep waking up

what to change once you know which one woke it up

the point of the log is that you change one thing instead of four. match the string to the switch:

• E_RX_IP_PACKET or E_TKO_ — wake for network access in System Settings → Battery → Options, or womp and tcpkeepalive in pmset. off only if you never reach this Mac remotely and share nothing from it.
• a name in Kernel Assertions — unplug that one device for a night. a dock or a hub is the usual answer, and one evening proves it.
• rtc/ anything — Power Nap, if you want fewer. these cost you nothing and are the ones the guides go after hardest; a named entry in pmset -g sched tracks back to the app, and user-invisible ones have no switch at all.
• HID Activity — nothing to configure. something is touching the machine; a Bluetooth mouse in a drawer is the classic, and System Settings → Bluetooth → Advanced stops that half.

the same power management that logs all this is what hop's module talks to when you want the Mac to stay up on purpose: keep Mac awake

when it never went to sleep, instead of waking up

different symptom, different command, and mixing the two is why people decide the machine is haunted. a Mac that never slept is held by an assertion, and plain pmset -g says so in one line: sleep 1 (sleep prevented by …), names in the brackets. pmset -g assertions then adds the process id and how long the hold has run.

the full walk through that symptom, including the flag and what to do about it, lives next door: keep a MacBook awake with the lid closed

and if the hold turns out to be an app you installed for exactly that purpose: Amphetamine alternative

how the same events look in the unified log, past what pmset prints: The Eclectic Light Company — waking your Mac from sleep, log highlights

frequently asked questions

how do i see why my Mac woke up?

pmset -g log | grep -i "wake from" in Terminal. every wake is recorded, and the cause is the text after the words «due to» — not the code in the square brackets, which is the sleep state it came out of.

is it bad that my Mac wakes up many times a night?

not by itself. eight days of log on the Mac this page was written on held 46 wakes, 37 of them dark: the display stayed off, a short task ran, the Mac went back down. that is the design working, not a fault.

what does E_RX_IP_PACKET ARPT mean in the wake log?

a packet arrived over Wi-Fi and the wireless chip woke the Mac to deal with it. it is the most common reason in a normal log, and it is «wake for network access» — womp in pmset — behaving as configured.

why do i not see EC.LidOpen in my wake log?

because you are on an Apple silicon Mac. EC.* strings came from the embedded controller in Intel Macs. Apple silicon writes HID Activity, pwrbtn, smc.sysState.Wake and NUB.SPMI instead.

should i turn off wake for network access?

only if you never reach this Mac remotely and do not share anything from it. check pmset -g custom first: womp is set separately for battery and for AC, so it may already be off on one of them.

does power nap cause this?

Power Nap produces dark wakes, not full ones — they show up as rtc/Maintenance and rtc/SleepService. if your screen is lighting up, something else is responsible.