Your Mac woke 33 times last night.

You closed the lid at 23:45. It spent 40 minutes running before you opened it again. macOS wrote down every one of those wakes — the reason, the process, the battery level — and then buried it in 85,000 lines of pmset -g log that nobody has ever read.

Free · MIT · No account, no network, and not one permission prompt.

~ — darkwake

    

Real output from the MacBook this was written on. Nothing here is mocked up.

What it found on the machine that built it

Seven nights of an ordinary laptop, doing nothing unusual.

244

wakes across seven nights with the lid shut. Twenty to seventy every single night.

3h 3m

spent awake and running while it looked, to anyone in the room, switched off.

59h 38m

coreaudiod holding an assertion that stops the machine going to sleep.

One glance, from the menu bar

The icon fills orange the moment something takes hold of sleep, and goes quiet when your Mac is free to rest. Click it for last night.

Right now

2 things are stopping it from sleeping.

sharingd
Handoff
WhatsApp
held by runningboardd
Last night · Sat 29 Aug

Your Mac was shut for 8h 20m and woke 33 times, running for 40m of it.

What woke it
Scheduled maintenance
21× · 26m
macOS's own timer: backups, indexing, updates
Wi-Fi traffic
10× · 13m
“Wake for network access” — something on your network pinged it
Held sleep open
coreaudiod
8h 20m
Brave Browser
1h 43m

It says what the wake actually was

macOS records smc.sysState.Wake(0x70070000) wifibt wlan E_TKO_TCP_DATA ARPT/. DarkWake says “Wi-Fi traffic — that's Wake for network access, and tells you where to turn it off.

It names the app, not the daemon

runningboardd holds assertions on behalf of other apps and buries their names in the reason string. Blaming the daemon helps nobody, so DarkWake digs out the app.

It never asks you for anything

Two shell commands that need no privileges: pmset -g log and pmset -g assertions. No root, no Screen Recording, no Accessibility. There is no network code in the program.

Why nobody had done this

The data has been sitting on every Mac for a decade. Every article about overnight battery drain ends the same way: “run pmset -g log | grep and read it yourself.” Two things make that unreadable, and both are just work nobody wanted to do.

The reasons are hardware tokens

Wake causes are strings like NUB.SPMI0.SW3, AOP.TrustedOutboxNotEmpty, E_TKO_TCP_DATA. They come from the power controller, not from anything meant for a person. Mapping them to plain English is most of what this program is.

The arithmetic is a trap

Each released assertion says how long it was held — but the hold often began before the night you are looking at, and coreaudiod holds one per audio context. Adding them up gives “coreaudiod: 279 hours” inside an eight-hour night. DarkWake clips every hold to the window and unions the overlaps, so a night can never contain more than a night.

Install

Swift and AppKit, no dependencies, no Xcode project. Builds in about four seconds.

$ git clone https://github.com/nickzsche21/darkwake $ cd darkwake && ./build.sh $ open build/DarkWake.app # the menu bar app $ ./build/darkwake --week # or just the CLI

Everything it does

darkwakeLast night: what woke it, and what it cost.
darkwake --weekEvery night macOS still remembers.
darkwake --nowWhat is holding your Mac awake this second.
darkwake --jsonThe whole analysis, machine readable.
darkwake --render p.pngDraw the panel offscreen, light and dark.
darkwake --statsParser sanity numbers, so you can check the work.

What it can't do

Written down here rather than discovered by you later.