Who wakes your Mac at night?

Recounted 19 August 2026 after we found a mistake in our own method · six consecutive nights of one MacBook Pro's own power log, plus seven nights of a second Apple silicon Mac for comparison · every number below is from those logs, and the command to reproduce it on your own Mac is at the bottom

Your Mac does not sleep through the night. It wakes, does something for half a minute, and goes back to sleep. This happens dozens of times, without lighting the screen or making a sound. macOS records every one of these wake-ups and the service that asked for it, in a log almost nobody reads. WattMate reads it, and so can you.

Here is what six nights of that log looked like on the machine this page was written on.

Correction, 19 August 2026: we recounted, and we had it wrong

The first version of this page named the Calendar's travel engine as the biggest requester on this machine. That was our own counting mistake. Here is exactly what it was, because a page that asks you to trust its numbers owes you the failures too.

Wake Requests is not a log of wakes that happened. It is the schedule of pending ones, and macOS reprints the entire list every time the Mac goes to sleep, so one deferred request appears dozens of times over, until it finally fires. We counted every appearance as a separate request.

The damage isn't noise, it's the ranking. The inflation is uneven. On a current log holding 1,437 raw entries that describe 777 actual requests, powerd was multiplied by 6.0 and the Calendar's alarm by 9.2, while every dasd branch and the DHCP renewal were multiplied by 1.0. Counting raw entries promotes whatever is scheduled furthest in advance, not what wakes you most.

Corrected, the headline reverses. Counting each request once and keeping only the ones macOS marks as having fired, the search indexer everyone blames really is the top requester here, and the Calendar falls to sixth. We told you the folklore was wrong; our arithmetic was wrong, and the folklore was closer than we were. The share of requests carrying a name goes up, from 66% to 90%.

What changed and what didn't. The wake-up counts and durations were never affected: they come from the sleep and wake events, not from this list. The request tables are recomputed on a fresh six-night window on the same machine, because pmset keeps only about a week of log and the original one is gone. The fix is in the script at the bottom of this page.

The numbers

Who asked

At the surface, a handful of system daemons place all the requests. Counted by the ones that actually fired: dasd, the task scheduler (76%), powerd (13%), PowerUIAgent (6%) and mDNSResponder, the network discovery service (5%). Note how far this is from the raw count, where powerd appeared to place half of everything: it schedules early and often, so it dominates a list of pending requests without waking the machine proportionally.

But those are messengers. The interesting part is the info= field, where the scheduler records whose task it is actually running. Across the week, the most frequent real requesters were:

Not one of these is a bug, and not one of them is an app you installed. This is the machine keeping calendars, search, network address and diagnostics current while you sleep: the everyday cost of a computer that's ready when you open it.

The detail worth pausing on: two thirds of the wakes on this machine come from four services you never installed and cannot see in any settings pane. They are search indexing, disk-encryption reporting, widget refreshes and on-battery maintenance. And note what the correction did to the story. Under the broken count the answer was surprising and quotable; under the correct one it is ordinary. That is usually the direction honest arithmetic moves, and it is the reason to run the log yourself rather than trust anyone's headline, including ours.

Then we ran it on a second Mac, and almost nothing matched

Before publishing we repeated the whole analysis on a different Apple silicon Mac, seven nights, same filters. We expected the numbers to move a little. They moved a lot:

Ten times the wake-ups, a ninth of the duration each, a different culprit. Mac 2's two request figures are struck through above: they were produced by the same broken count, that machine is not at hand to recompute, and we would rather show a hole than a number we no longer trust. So the honest headline isn't "Calendar wakes your Mac". It's this: the answer is specific to your machine, and it is written down on your machine. Which is exactly why a page like this is worth less than five minutes with your own log.

What this does and doesn't prove

These are two Macs, not a population. Yours will differ again: more calendars, more mail accounts or a busier network mean more wake-ups; Power Nap off and Wi-Fi disconnected mean fewer. Treat the numbers as a demonstration of what the log contains, not as an average of all Macs. We're not going to dress up n=2 as a study.

Even the method has a tolerance, and it can be much worse than a tolerance. On the earlier window, recounting with slightly different episode filters moved the totals a few percent: 132 wake-ups instead of 124, 36 seconds instead of 30. Same log, same machine, defensible choices, and the third digit moves. But the correction at the top of this page is the larger lesson: a method error does not always announce itself in the third digit. That one changed the answer to the question the page exists to ask. We publish the script below precisely so that you can disagree with our filters, and catch us again.

We deliberately do not price a single wake-up. It's the number everyone wants ("so how much battery did those 88 wakes cost?"), and it can't be measured honestly: macOS reports charge in whole percent, and a 45-second wake doesn't move a whole percent. Anyone who gives you milliwatt-hours per wake is modelling, not measuring. What can be measured honestly is the count, the duration and the requester's name, so that's what we report, on this page and in WattMate.

Silent doesn't mean harmless, and it doesn't mean harmful either. Dark wakes are the design working as intended. The reason to know about them is the outlier case: when one service starts waking the machine hundreds of times or holding it awake for minutes at a stretch, that shows up in exactly this log, and nowhere else in the interface.

Reproduce it on your own Mac

No app needed for the raw material: macOS keeps the log itself. In Terminal:

pmset -g log > ~/Desktop/power.txt

Then look for the lines labelled Wake Requests. Each one carries process= (which daemon asked), wakeAt= (when) and often info= (whose task it really is). Lines containing DarkWake are the silent wake-ups.

Two things to know before you count, both of which we got wrong the first time. The list is a schedule, reprinted in full at every sleep, so the same request recurs many times over. Identify a request by its info= and wakeAt= together, and count it once. And the one that actually won the race is marked with an asterisk before process=; on our log only 33% of scheduled requests ever fired. Count the asterisks, not the lines.

What WattMate adds is that you don't have to do this: it reads the same log and turns a night into plain language: how long the Mac slept, how often it woke, who asked, and how much of that time carries a name. Alongside the part of the product that measures the waking day: which app is using the battery in watts, and what quitting it is worth in minutes, verified afterwards.

Methodology and limits for everything we measure: how we count. Related: what to expect after the macOS 27 update · does quitting apps actually help? · where the charge goes with the lid closed

Journalists and researchers: the raw log analysis behind this page is available on request: support@wattmateapp.com. We'd rather you check it than trust it.