macOS 27 Battery Drain Overnight? Find What Wakes Your Mac

You close the lid at 100 percent, and in the morning the Mac is warm and the battery is at 40, or 20, or dead. Since macOS 27 Golden Gate shipped on 14 September, that story has turned up again and again in Apple's support forums: MacBooks that lose a frightening amount of charge while they are supposed to be asleep, or sitting idle on a desk, and run warm while doing it. The usual advice, "wait for Spotlight to finish" and "close some apps", does not help someone who is three weeks in and still losing a third of the battery overnight. This guide takes a different approach. Instead of a list of generic tips, it shows you how to measure what your Mac actually did overnight, using the logging tools built into macOS, how to read the output, and what to do about each pattern. It also covers the two specific runaway processes people have reported, replicatord and agentstored, what is and is not known about them, and what to send Apple so the report is actually useful.

Key Takeaways

• The reports are real and not acknowledged by Apple. The main Apple Support Communities thread shows 73 "Me too" clicks and 16 replies as of 14 October. No Apple employee has commented, and Apple describes 27.0.1 only as bug fixes.
• Not every Mac is affected. One long-standing forum contributor reports about 10 hours of battery use on a 16-inch M4 Pro MacBook Pro with 50 percent left. Measure your own Mac.
• Measure before you change anything. pmset -g log records every sleep, wake and DarkWake with a reason, and pmset -g assertions shows who is holding the Mac awake right now.
• A wake reason is a clue, not a verdict. Maintenance wakes are routine. A DarkWake every 15 minutes, or one lasting many minutes, is the pattern worth chasing.
• Two process cases exist. A user fixed a replicatord pinned at 100 percent by renaming its database files. agentstored has no known fix.
• Skip cleaners, SIP changes and repeated resets. If the Mac is still bad after careful measurement, report it with a sysdiagnose.

What People Are Actually Reporting

The most detailed report is the Apple Support Communities thread "Severe Battery Drain and overheating on MacBook Pro M5 after upgrading to macOS 27 Golden Gate", started on 22 September. When we read it on 14 October, it showed 73 "Me too" clicks and 16 replies across two pages. The original poster describes a MacBook Pro (M5 Pro, bought in May 2026) that barely lost charge overnight before the upgrade. Afterwards, unplugged and unused, "by the next morning the battery can be completely drained", and the machine felt hot while idle. In one test it went from roughly 100 percent to 1 percent in about 16 hours while supposed to be asleep.

Other reports in the thread, all user statements we cannot verify:

• A MacBook Air M5 owner says battery life fell from more than ten hours to four or five.
• A 16-inch M4 Pro owner says two days became six hours, though a volunteer noted the attached screenshot shows the display on, so the Mac was not asleep.
• An M3 MacBook Air owner on 27.0.1 says it "completely drained itself while not even using it" twice.
• A MacBook Air M5 owner on a 27.2 build says it "got worse" with each update.
• A MacBook Pro M5 owner posted on 8 October that the Mac wakes into DarkWake about every 15 minutes, with the log blaming wifibt and SMC.OutboxNotEmpty, even with Wi-Fi and Bluetooth switched off.

Two caveats. The original poster wrote on 27 September that uninstalling applications "deprecated for this macOS version" returned the Mac to normal, without naming them: an anecdote, not a general fix. And Apple has not acknowledged a battery problem in macOS 27; a volunteer in the thread notes that Apple does not participate in the forum. The only official statement we found is the description of 27.0.1 (build 26A434, 28 September) on Apple's security releases page, which does not mention battery life.

What Is Normal After a Major Upgrade (and How Long)

Every major upgrade triggers background work: Spotlight rebuilds its index, Photos re-analyses the library, iCloud re-syncs, and on a Mac with Apple Intelligence the on-device models may download. A Mac that is warm on day one is usually fine by day four.

Apple does not publish a duration. We searched Apple's support pages and found none. Third-party guides quote figures such as 72 hours, but none cites Apple. The time scales with library size and with how much time the Mac spends idle and plugged in.

Sign	More likely normal indexing	More likely a real problem
Time since upgrade	One to three days	A week or more, as in the main thread
Where the heat is	Mac open, plugged in, you walked away	Mac closed or in a bag, on battery
Processes	mds_stores, photoanalysisd, cloudd busy, then settling	One process pinned at 100 percent of a core for hours
Pattern over days	Each night a little better	Flat or worse

For the individual causes, see Spotlight reindexing after macOS 27, where the 30 GB went after upgrading (a volunteer in the main thread cites a case of rapid drain on a Mac with only 8 GB free) and Apple Intelligence stuck on preparing. One Community contributor also states that Apple Intelligence cannot be switched off in macOS 27; we could not confirm that, so we build no advice on it.

Step 0: Make Sure It Is a Sleep Problem

1. Run a controlled test. Charge to 100 percent, unplug, close the lid, note the time, and leave it for a set period such as eight hours. Write down the percentage when you open it. Repeat on a second night.
2. Keep your normal setup. Leave the Bluetooth mouse and dock as they usually are, so the test reproduces your real overnight state.
3. Check the Mac really slept. A volunteer in the thread notes that closing the lid "may not put the laptop to sleep", because anything holding a sleep assertion keeps it awake. An awake Mac in a bag drains fast and gets hot.

The result is a label: "awake all night", "intermittently awake", or "asleep and still drained". The next steps tell you which.

The Measurement Toolkit: Four Commands and One App

All commands below are documented in macOS's own manual pages, which you can read with man pmset, man top and so on. The syntax here matches the macOS 27.0.1 manual pages. We say plainly where we are describing log formats that Apple does not document: the output of pmset -g log is described by the manual only as "a history of sleeps, wakes, and other power management events. This log is for admin & debugging purposes." The interpretation of the individual lines below is informed reading, not Apple documentation.

One zsh gotcha first: in macOS's default shell, log is a shell built-in, so log show fails with "too many arguments". Always write the full path, /usr/bin/log, as the examples do.

Command 1: pmset -g stats, the one-line overview

pmset -g stats

The manual describes -g stats as printing "the counts for number sleeps and wakes system has gone thru since boot". The output is three lines: a Sleep Count, a Dark Wake Count and a User Wake Count. This is your first sanity check. If you rebooted a day ago and see a Dark Wake Count in the hundreds, the Mac is waking itself a lot. The reporter in the main thread saw "225 Sleep/Wakes since boot, and one sleep cycle showed 7 Dark Wakes".

A high count is not automatically bad: a DarkWake is a partial wake in which the display stays off and the Mac does background work for a few seconds, and Macs do this routinely for maintenance. A volunteer in the thread states that most DarkWakes use almost no battery and last under a minute, and that a 15-minute DarkWake on their own Mac was unusual. Those are one person's observations, but they match the point that matters: the count tells you whether to look; the durations and reasons tell you what you are looking at.

Command 2: pmset -g log, the sleep and wake history

pmset -g log | awk '$4=="Sleep"||$4=="Wake"||$4=="DarkWake"' | tail -60

The log can be tens of thousands of lines long, most of them power assertions. The filter above keeps only the Sleep, Wake and DarkWake entries. A forum volunteer posted a shorter grep with double spaces, grep -E 'Sleep |Wake ', which works because the type column is padded, but it also catches a few assertion-summary lines, so the awk version is cleaner. Each kept line begins with the date, the time and the time zone, then the event type, then the details.

Here is what a healthy overnight sequence looks like on macOS 27, with the content lightly edited for clarity:

09:00:41 Sleep      Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:100%) 31 secs
09:01:12 DarkWake   DarkWake from Deep Idle [CDNP] : due to smc.sysState.Wake(0x70070000) USB-C_plug SMC.OutboxNotEmpty Using BATT (Charge:100%) 0 secs
09:01:13 Sleep      Entering DarkWake state due to 'Notification Wake Back to Sleep':TCPKeepAlive=active Using AC (Charge:100%) 108 secs
09:03:01 Wake       DarkWake to FullWake from Deep Idle [CDNVA] : due to UserActivity Assertion Using AC (Charge:100%)

Read each line left to right:

• Event type. Sleep is the Mac going to sleep or falling back into DarkWake. DarkWake is a wake without the display. Wake is a full wake. Entering ... state due to 'Reason' tells you why it went to sleep.
• The reason in quotes. Maintenance Sleep, Sleep Service Back to Sleep and Notification Wake Back to Sleep are the Mac finishing a background session. Clamshell Sleep is the lid being closed. Idle Sleep and Software Sleep are timer or app requests.
• TCPKeepAlive=active. The Mac was keeping TCP connections alive during sleep, which is the standard behaviour with the tcpkeepalive setting at 1.
• The wake reason after "due to". This is the string you care about most. Examples are covered in the table later in this article.
• Using BATT or Using AC and the charge in brackets. This is the power source and the battery percentage at that moment. Comparing the Charge values across the night gives you a drain curve without any third-party tool.
• The number of seconds at the end. It appears to be how long the Mac spent in the state it just left, though Apple does not document it. A DarkWake that ends with Sleep ... 31 secs was awake about half a minute; one that ends with several hundred seconds was awake for minutes.

To turn the log into a drain curve, print only the time, event type and charge:

pmset -g log | awk '$4=="Sleep"||$4=="Wake"||$4=="DarkWake" {match($0,/Charge:[0-9]+%/); print $1,$2,$4,substr($0,RSTART,RLENGTH)}' | tail -80

To count DarkWakes per hour, which makes a 15-minute rhythm obvious:

pmset -g log | awk '$4=="DarkWake"{print $1, substr($2,1,2)":00"}' | sort | uniq -c | tail -24

On a Mac that sleeps properly, you will see a handful of DarkWakes each hour. The report from 8 October in the main thread, in which a MacBook Pro M5 woke about every 15 minutes through the night and during the day, would show up as a steady four per hour, with some individual wakes lasting 20 seconds or more. That is not conclusive on its own, but it is a rhythm worth explaining.

Command 3: Wake Requests, who asked for the next wake

The same log also records scheduled wake requests, which are the Mac planning its own future wakes. They look like this, shortened:

pmset -g log | grep "Wake Requests" | tail -3

Wake Requests  [process=mDNSResponder request=Maintenance deltaSecs=7198 wakeAt=... info="upkeep wake"]
               [process=dasd request=SleepService deltaSecs=1016 wakeAt=... info="com.apple.dasd:501:..."]
               [process=powerd request=TCPKATurnOff deltaSecs=316236 wakeAt=...]

Each bracket is one request: the process that asked, the request type, how many seconds from now (deltaSecs), and a free-text info string. This is the closest the system gives you to a list of suspects. The dasd entries are the Duet Activity Scheduler, which schedules background tasks and can wake the Mac to run them; the long info strings name the task. On the main thread, a reporter listed tasks that appeared in their log, including com.apple.intelligenceflow.toolbox.update.fastpass, Screen Time history cleanup and PowerUIAgent maintenance. Those are names from one person's Mac, not proof of a bug. If the same unusual task name appears in every wake request through the night, that is your lead. For the scheduler's mechanics, see our article on dasd and appstoreagent running overnight.

Command 4: pmset -g assertions, who is holding the Mac awake right now

pmset -g assertions

The manual says this "displays a summary of power assertions. Assertions may prevent system sleep or display sleep." An assertion is a request from a process: "do not sleep while I am doing this". The top of the output is a summary table of counts; below it, "Listed by owning process" names each holder. Focus on these:

Assertion	Meaning	What a non-zero value suggests
PreventUserIdleSystemSleep	Something is preventing idle sleep	A process (video, download, caffeinate, a remote-access tool) wants the Mac awake
PreventSystemSleep	Stronger: prevents sleep entirely	Rarely good; common with some hardware or audio workflows
PreventUserIdleDisplaySleep / InternalPreventDisplaySleep	The display is being kept on or has a pending timeout	Normal if you are using the Mac
BackgroundTask	A background task is running	Usually temporary; persistent value points to a stuck task
NetworkClientActive	Network activity is holding the Mac awake	A transfer or sync in progress
UserIsActive	The Mac believes you are using it	Often a Bluetooth mouse or keyboard event

Run it twice. First run it while the Mac is idle with the lid open, and again right after you wake the Mac in the morning. The reporter in the main thread ran it and found no permanent blocker: PreventSystemSleep, BackgroundTask and NetworkClientActive were all 0, with a few temporary entries such as one from coreaudiod and a kernel assertion tied to a networking client. A volunteer replied that macOS creates a lot of temporary assertions and that they rarely help find the cause. That matches our experience: assertions are most useful for the "awake all night" case, and least useful for the "waking repeatedly" case.

For a log of assertions as they are created and released, pmset -g assertionslog streams them live, and you can also search history:

pmset -g log | grep -E "Assertions" | grep -i "created" | tail -30

The assertion lines in the log name the owning process and the reason string, for example a "Video Wake Lock" from a browser or a "caffeinate command-line tool" entry. If one app creates and releases an assertion repeatedly through the night, that app is a suspect.

Command 5: pmset -g and friends, the settings in effect

pmset -g
pmset -g custom
pmset -g cap
pmset -g sched

-g prints the settings in use, -g custom separates battery from adapter, -g cap lists the features this Mac supports, and -g sched lists scheduled wakes. The main thread's reporter had powernap = 1, tcpkeepalive = 1, womp = 0, standby = 1 and hibernatemode = 3, which are ordinary laptop values. Per the manual, powernap toggles Power Nap, womp is the same as "Wake for network access" in System Settings, and hibernatemode 3 (the portable default) keeps memory powered with a copy on disk. tcpkeepalive is not described in the manual's settings list, though it appears in the output and the log (TCPKeepAlive=active).

Some guides say to set tcpkeepalive 0 or powernap 0 straight away. We have not verified what those changes do on macOS 27 beyond the manual, so change one setting at a time, only after a measurement points at it, and note the old value so you can undo it.

The app: Activity Monitor's Energy tab, plus top

Open Activity Monitor, click Energy, and sort by 12 hr Power (right-click the header to add the column). The Preventing Sleep column shows which process holds a sleep assertion, linking this tab to pmset -g assertions. A process with high 12 hr Power but low CPU is probably waking the Mac often rather than computing, which is exactly what a wake log shows.

In Terminal:

top -l 2 -n 8 -o cpu -stats pid,command,cpu,idlew,power

-l 2 takes two samples (the second has real deltas), -n 8 shows eight processes, and -stats picks columns. idlew is idle wakeups and power is an energy score; both are accepted by top in macOS 27.0.1, though the manual does not describe them. Large values flag suspects even when the CPU percentage looks small.

Reading the Log: What You See, What It Means, What to Do

Here is the decision table. Wake reasons below are real strings that appear in pmset -g log on macOS 27; their meanings are our reading of the strings, which Apple does not document, so treat the third column as a way to proceed, not as proof.

What you see in the log	What it probably means	What to do
Clamshell Sleep followed by long gaps with few DarkWakes	Lid closed, Mac sleeping normally	Nothing; this is the healthy shape
rtc/Maintenance or request=Maintenance roughly every two hours	Scheduled maintenance wake, owned by mDNSResponder in the sample above	Normal
rtc/SleepService with a dasd request naming a task	Background task scheduled by DAS	Check the task name in Wake Requests. Many wakes with the same name is a lead
smc.sysState.Wake(0x70070000) wifibt SMC.OutboxNotEmpty	The Wi-Fi/Bluetooth chip asked the SMC for a wake	A few per night are normal. Dozens at 15-minute intervals are the 8 October pattern; test with devices removed (see below)
USB-C_plug, acdetach	A power or USB event	Physical: a dock, hub, charger or cable. Unplug and retest
UserActivity Assertion	Something declared you were active	A Bluetooth mouse or keyboard, a trackpad touch, or an app calling the user-active API. Check pmset -g assertions for "Bluetooth LE HID Activity"
A DarkWake that lasts many minutes	Something is doing real work	Capture the unified log for that window (see below) and check Activity Monitor next time
Back-to-back Wake Requests that all name the same process	That process keeps rescheduling itself	Note the name; if it is dasd, search the info string
InternalPreventSleep from powerd named com.apple.powermanagement.darkwakelinger, timing out	Power management keeping the Mac awake briefly after a DarkWake	A short timeout is likely routine; the reporter listed it, Apple does not document it. Look at the duration, not the name
No Sleep entries at all overnight; the Charge falls steadily	The Mac never slept	This is the "awake all night" case. Run pmset -g assertions; check lid, external devices, caffeinate, remote sessions
Normal sleep log, but the Charge still falls much faster than before	Asleep but draining	Suspect hardware or a firmware problem. See the battery health section

To dig into a single wake, use the time stamp from the log. In the main thread, a volunteer posted this template, and it is the documented way to read the unified log between two times:

/usr/bin/log show --start "2026-10-14 03:14:00" --end "2026-10-14 03:16:00" --style compact > ~/Desktop/wake-window.txt

Use the exact times from your own pmset -g log entry for the DarkWake you want to examine, and save the output to a file, because it is large. The volunteer also warned that this log is full of harmless-looking errors and warnings and that finding a single culprit can be difficult, which we agree with. If you know the process name already (from Activity Monitor or Wake Requests), narrow the search:

/usr/bin/log show --last 30m --style compact --predicate 'process == "powerd"'

--last 30m limits the window, --style compact shortens each line, and --predicate filters by process or subsystem. Replace powerd with the process you are investigating. The log only goes back a limited time, so run this soon after the event. Run it as your normal user; add sudo if you need system-level entries.

Where Apple silicon differs

• No separate SMC reset. A restart does what the old reset did; see our NVRAM, PRAM and SMC guide. The log still shows smc.sysState strings because the text comes from the power controller.
• Available pmset keys depend on the Mac. pmset -g cap shows what yours supports.
• Hibernation is on by default for portables (hibernatemode 3), so a long sleep can lose a little charge until standby kicks in.
• Wake-reason strings differ from Intel. Old articles cite EC.LidOpen; on Apple silicon expect smc.sysState.Wake, NUB.SPMI, rtc/Maintenance and named hardware like wifibt. Eclectic Light's 2017 walkthrough explains the structure of a wake, but its strings are Intel-era.

Case Study 1: replicatord at 100 Percent CPU

The Apple Support thread "replicatord running at 100% CPU on macOS 27" was posted on 17 September by an M1 Pro MacBook Pro owner on macOS 27.0. Killing the process or restarting did not help. When we read it, it showed two replies and no "Me too" count.

We could not find an Apple description of replicatord, and we will not guess. The thread gives a method and a fix that worked for one user:

1. A volunteer advised leaving the LaunchAgent enabled, testing in Safe Mode, and using View > Sample Process in Activity Monitor.
2. The poster's sample showed the CPU time "nearly completely spent in SQLite database access", so they suspected a corrupted database.
3. Using lsof, they found it in ~/Library/Group Containers/group.com.apple.replicatord/replicatord/.
4. They renamed replicatord.sql, replicatord.sql-shm and replicatord.sql-wal, killed the process, and it "came back and created a fresh db. CPU consumption now is back to normal."

That is a user-reported fix on one Mac, not confirmed by Apple. To try it reversibly:

cd ~/Library/"Group Containers"/group.com.apple.replicatord/replicatord/
ls -la
mkdir -p ~/Desktop/replicatord-backup
cp -p replicatord.sql* ~/Desktop/replicatord-backup/
mv replicatord.sql replicatord.sql.old
mv replicatord.sql-shm replicatord.sql-shm.old
mv replicatord.sql-wal replicatord.sql-wal.old
killall replicatord

If Terminal says "Operation not permitted", macOS privacy protection may be blocking access; Full Disk Access for Terminal is one way through, but it is broad, so remove it afterwards. To undo: run killall replicatord, delete the new replicatord.sql* files, rename the .old files back, and let the process restart. We cannot tell you what this database holds, which is why the steps rename and back up instead of deleting. If CPU returns to 100 percent, undo and report it. This only helps if replicatord is actually on your CPU list.

Case Study 2: agentstored, and Why There Is No Fix Yet

A MacRumors thread, "AgentStored process constantly running on Golden Gate", was a day or two old with no replies when we read it on 14 October. The poster says agentstored, under /System/Library/PrivateFrameworks/AgentSessionKitRuntime.framework, "is sitting at 100% on one core nonstop, even right after a reboot", with "34+ hours of CPU time and written ~39 GB to disk". Turning off Automatic Visual Look Up and moving the AgentSessionKit database out of ~/Library/Daemon Containers did not help.

• We found no Apple documentation for agentstored, so we will not say what it does.
• There is no known fix, and it is a single report without independent confirmation.

You can still measure it. In Activity Monitor, check CPU Time in the CPU tab and Bytes Written in the Disk tab, then use View > Sample Process and keep the sample for a Feedback Assistant report. Do not delete files from ~/Library/Daemon Containers as an experiment; the reporter already moved one database without result. Sustained heavy writes are a reason to report sooner rather than wait.

Settings That Legitimately Reduce Sleep Drain

These change how often the Mac wakes, not a bug. We checked paths against Apple's Mac User Guide pages, which list macOS 27 first in the version selector.

Setting	Where	Notes
Wake for network access	System Settings > Battery > Options (laptops); Energy (desktops)	Apple's page says to choose a less frequent option, such as plugged in only or never, to save battery. Verified
Low Power Mode / Energy Mode	System Settings > Battery	Set separately for battery and adapter. Verified
Optimized Battery Charging / Charge Limit	System Settings > Battery, Charging section, Info button	Protects battery lifespan; does not cut sleep drain. Verified
Power Nap	powernap key in pmset; older macOS: Battery > Options	Documented in the manual; we could not confirm the macOS 27 System Settings label
Bluetooth devices waking the Mac	Formerly Bluetooth > Advanced	A 2022 community thread says it was removed in Monterey; we could not confirm its status in macOS 27. Test by switching the device off before sleeping
Find My	Apple Account and Privacy settings	Exact macOS 27 path not confirmed; we do not recommend disabling it as a test

A forum reply also suggested turning off Summarize Notifications and reviewing System Settings > General > Login Items and Extensions; the second is a good habit after any major upgrade. To test Wi-Fi or Bluetooth, switch each off for one night, though the reporter with wifibt wakes saw them continue with both off.

Isolating Software

A volunteer in the main thread recommended the right splits:

1. Safe Mode. On Apple silicon, shut down, hold the power button until startup options appear, select the volume, hold Shift and choose Continue in Safe Mode. A clean log there implicates a third-party extension or login item.
2. A new user account. If its overnight pattern is clean, the cause is in your user's settings or data. Delete it afterwards.
3. Remove or update cleaners, optimizers and similar software, then list Login Items and Extensions and disable unfamiliar items one group at a time, comparing DarkWakes per hour between nights.

Charge-limit tools and menu bar managers have needed macOS 27 updates; see charge-limit apps on macOS 27.

When to Suspect the Battery or Hardware

If the log shows long uninterrupted sleeps but the charge still falls much faster than before, suspect the battery.

1. Open System Settings > Battery and click the Info button by the battery condition. Apple's macOS 27 page lists Battery Condition and Maximum Capacity.
2. Apple's battery service page defines "Normal" as "the battery is functioning normally" and "Service Recommended" as the battery's ability to hold charge being less than when new, or not functioning normally.
3. Run system_profiler SPPowerDataType | grep -E "Cycle Count|Condition|Maximum Capacity"; the Health Information section includes those three values.
4. For sudden jumps, leave pmset -g pslog running on battery. The manual says discontinuities such as 30 percent to 0 are "indicative of an aging battery".

Heat is covered in our MacBook Pro M5 overheating guide. A healthy battery plus a restless log means software.

What to Send Apple

The route to an engineer is Feedback Assistant. Apple's bug reporting page says it "automatically attaches a sysdiagnose for each issue" and that a sysdiagnose "should be included with all reports, even if you think one is not needed". Without a developer account, Apple's macOS feedback form is a simpler web option.

1. Capture a sysdiagnose soon after a bad night. The sysdiagnose manual names Control-Option-Command-Shift-Period as the trigger; sudo sysdiagnose from Terminal writes to /var/tmp by default and takes several minutes. It may contain private information.
2. Include the facts: macOS 27.0.1 (26A434), Mac model, upgrade or clean install, and your test results (start and end percentage, duration, lid state).
3. Attach the pmset -g log excerpt and pmset -g stats.
4. Name suspects with CPU time and bytes written, and what you ruled out: Safe Mode, new user, free space.

What Not to Do

• Do not install a "cleaner" or "optimizer". Volunteers in the thread say these cause post-upgrade compatibility problems, and none can fix a wake reason.
• Do not disable System Integrity Protection to kill a daemon. The renaming fix needs no such change.
• Do not delete random LaunchAgents or LaunchDaemons. A volunteer advised leaving Apple's agents enabled while investigating.
• Do not reset the SMC or NVRAM repeatedly. On Apple silicon a restart is the reset; see our reset guide.
• Do not change several settings at once, or judge from a single night.
• Do not erase and downgrade in a panic. Read the update decision guide and the downgrade guide first; the cause may be one app.

Troubleshooting Common Issues

My log shows no sleep at all overnight

Symptoms: pmset -g log has no Sleep entries between midnight and morning, and the Charge falls steadily.

Cause: Something kept the Mac awake. Candidates are an assertion from an app (video, download, remote access, caffeinate), a terminal session (the ttyskeepawake setting), a connected device, or a lid that did not close fully.

Solution:

1. Run pmset -g assertions and look at "Listed by owning process" for PreventUserIdleSystemSleep or PreventSystemSleep.
2. In Activity Monitor's Energy tab, check the Preventing Sleep column.
3. Quit that app normally and retest.

pmset -g assertions | grep -E "PreventUserIdleSystemSleep|PreventSystemSleep|caffeinate"

If that does not work: Disconnect all external devices, quit terminal and remote sessions, and run the controlled test again. If the Mac still never sleeps, include the assertions output in your report.

The Mac wakes about every 15 minutes with wifibt in the reason

Symptoms: DarkWake entries at regular intervals, each citing wifibt SMC.OutboxNotEmpty.

Cause: The wireless chip repeatedly asks the system to wake. This matches the 8 October report on the main thread, where the wakes continued even with Wi-Fi and Bluetooth switched off. We do not know the cause and Apple has not commented.

Solution:

1. Count the wakes per hour with the awk command above, and note the durations.
2. Remove Bluetooth accessories and switch off Handoff-related devices nearby, then retest.
3. Set Wake for network access to Never in System Settings > Battery > Options, and retest for a night.
4. Compare with Low Power Mode on.

If that does not work: This is a candidate for a Feedback Assistant report. Attach the DarkWake counts and a sysdiagnose from the morning after.

pmset -g log prints nothing useful, or the grep returns nothing

Symptoms: Empty output after the filter, or an error from log.

Cause: The grep -E 'Sleep |Wake ' pattern depends on exact spacing. In zsh, log is a shell built-in and fails with "too many arguments".

Solution: Use the awk filter, which keys on the event column, and use /usr/bin/log show for the unified log. If pmset -g log is empty after a reboot, give the Mac a few sleep cycles.

FAQ

Is macOS 27 battery drain while asleep a confirmed bug?

Not by Apple. Users on M3, M4 and M5 MacBooks describe heavy overnight drain in Apple's community forums, and other owners report no problems. We found no Apple acknowledgement and no known-issue entry, and 27.0.1 is described only as bug fixes. Treat it as a widely reported, unconfirmed pattern and measure your own Mac before blaming the update.

How long should Spotlight and Photos take after upgrading?

Apple does not publish a duration, and we found no official figure. Third-party guides mention a few days. The size of your library and how often the Mac sits idle on power both matter. If a Mac is still hot and draining a week later with the lid closed, as in the main thread, the explanation probably is not indexing alone.

What does a DarkWake mean and is it bad?

A DarkWake is a partial wake in which the display stays off and the Mac does short background work, such as maintenance, mail checks or network upkeep. Many per night are normal. A forum volunteer says most last under a minute. What matters is frequency, duration and whether the same reason repeats. A DarkWake lasting many minutes deserves investigation.

Can I safely kill replicatord or rename its database?

The only evidence is one user's report that renaming three database files in its Group Container folder and restarting the process brought CPU use back to normal. Apple has not documented the process. If you try it, back up the files first, rename rather than delete, and know how to restore the originals. Do not disable the daemon.

Should I turn off Power Nap or Wake for network access?

They are reasonable tests, not cures. Apple's page says choosing a less frequent option for network wake saves battery, and the powernap key is documented in the pmset manual. Change one setting at a time, run a controlled overnight test and compare DarkWake counts. We could not confirm the macOS 27 System Settings location of the Power Nap switch.

Will downgrading to Tahoe fix it?

Possibly, but there is no evidence that it is required for everyone, and it takes an erase and reinstall. Measure first: if one app or process is responsible, removing it is far cheaper. If your log shows the Mac itself waking repeatedly and you cannot tolerate it, the downgrade guide explains the cost.

What should I attach to a Feedback Assistant report?

Attach a sysdiagnose captured soon after the bad night, your macOS build (for example 27.0.1, 26A434), the Mac model, a log excerpt from pmset -g log, and the results of your controlled test with start and end percentages. Apple's own page says a sysdiagnose belongs with every report, so include one even if it feels redundant.

Conclusion

Some MacBook owners report heavy overnight drain on macOS 27, Apple has said nothing, and the reports do not point at a single cause. What you can do is measure: run a controlled overnight test, read pmset -g stats and pmset -g log to see whether the Mac slept, woke repeatedly or never slept, check assertions and Activity Monitor, and use the decision table. For replicatord there is a user-reported workaround to try with a backup; for agentstored there is only a clear report to file. If the log is healthy but the battery falls fast, check Battery Health before blaming software. If you decide the Mac is unusable now, see whether to update and downgrading.

Related reading: dasd and appstoreagent High CPU Overnight on macOS 27, Mac Sleep Problems Complete Guide, Spotlight Reindexing After macOS 27