MacBook Pro M5 Pro: DarkWake causing overnight battery drain

terriermind wrote:

It’s brand new (about a week old, AppleCare+), and I’m seeing about 20% battery drain overnight while the lid is closed and it should be sleeping.

What’s confusing is that during normal use, battery life is excellent. For example, I watched ~1.5 hours of Apple TV in high quality and only lost about 5%, so the battery itself seems solid.

How long is overnight? If it's draining 5% in 90 minutes, that would equate to 40% battery drain overnight. So it's definitely less.

What I’ve tested so far:•

Fully quit all apps (Cmd+Q, not just closing windows)

You cannot quit all apps. Some have background components that run constantly. When the Mac wakes overnight, all previously running apps will resume, not including anything related to displays and a few other things.

• Tried to leave it unplugged again overnight , battery at 100%

Why not just plug it in?

From what I can tell, it looks like the system is waking frequently for:

network activity (WiFi / mDNSResponder)

• background tasks (SleepService / dasd)

Yes, by design.

It seems like a DarkWake loop caused by network/background services, not hardware or battery-related.

DarkWake is an OS functionality. That's just how it works and has worked for over a decade.

Not panicking since it’s under warranty, just trying to understand whether this is expected behavior, a macOS bug, or something misconfigured.

This is expected behaviour. While it is a mobile device, if it's turned on, it will consume energy. The expected behaviour is that the device will be plugged in overnight.

This is expected behaviour. While it is a mobile device, if it's turned on, it will consume energy. The expected behaviour is that the device will be plugged in overnight.

Just checked and my Mac lost 3% charge last night. The OP's Mac has certainly got some sort of problem and whilst plugging it in overnight might fix the symptom it doesn't address the cause.

terriermind wrote:

Thank you. I've learned a lot since I've posted this and looking back my hyperbolic language seems silly now that I understand how the system works. I do thank you, and the others that take their time to help out newbies. It is very much appreciated.

You're welcome. Glad we could help.

There is not a lot of good information online about any of these things. I'm still trying to figure my way around. I know some of what we suggest may sound outrageous, but that is just the nature of macOS these days. I understand how frustrating it can be....I have to do this more often than I like for my organization. I actually need to start writing some of these things down so I don't forget them & to pass them on to others.

I'm having the exact same issue with a brand new MacBook Air Apple M5. I'm currently running macOS Tahoe 26.4. My battery routinely drains 30-40% overnight, even with apps closed. I've had multiple Mac products (two Macbook Pro's, one Macbook Air) and never experienced this before.

As changing from load to bootstrap didn't work, below is the final Revised version from Gemini that I'm using.

In my case Darkwakes are minimal now:

% pmset -g log | grep -e "Entering Sleep" -e "Wake from" -e "DarkWake" | tail -n 10 

2026-06-25 02:00:42 +0200 Sleep         Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using Batt (Charge:69%) 516 secs  

2026-06-25 02:09:18 +0200 DarkWake       DarkWake from Deep Idle [CDN] : due to NUB.SPMI0Sw3IRQ nub-spmi0.0x02 rtc/Maintenance Using BATT (Charge:69%) 45 secs  

2026-06-25 02:10:03 +0200 Sleep         Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using Batt (Charge:69%) 5250 secs 

2026-06-25 03:37:33 +0200 DarkWake       DarkWake from Deep Idle [CDN] : due to AOP.Outbox0_NotEmpty AOP.MBIEndpoint.38 spu_queue_overflow_ep38/ Using BATT (Charge:69%) 45 secs  

2026-06-25 03:38:18 +0200 Sleep         Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using Batt (Charge:69%) 5260 secs 

2026-06-25 05:05:58 +0200 DarkWake       DarkWake from Deep Idle [CDN] : due to AOP.Outbox0_NotEmpty AOP.MBIEndpoint.38 spu_queue_overflow_ep38/ Using BATT (Charge:69%) 45 secs  

2026-06-25 05:06:43 +0200 Sleep         Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using Batt (Charge:68%) 3552 secs 

2026-06-25 06:05:55 +0200 DarkWake       DarkWake from Deep Idle [CDN] : due to NUB.SPMI0Sw3IRQ nub-spmi0.0x02 rtc/Maintenance Using BATT (Charge:68%) 45 secs  

2026-06-25 06:06:40 +0200 Sleep         Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using Batt (Charge:68%) 1866 secs 

2026-06-25 06:37:46 +0200 Wake         Wake from Deep Idle [CDNVA] : due to smc.sysState.Wake(0x70070000) lid SMC.OutboxNotEmpty RTP.multi-touch/HID Activity Using BATT (Charge:68%)      

No, it's not. Don't you get that I've paid a lot of money for this device and I should be the one in control, not Apple? Besides, the problem exists not only when I'm at home, but also on a trip when my Mac is in my backpack where it gets hot.

As was mentioned already Windows laptops act similarly, but they have an option to hibernate whereas Apple wants to manage it by itself.

People agreed to give up so much for the sake of convenience and now corporations are exploiting that against us every where they can.

If it's not a problem then posts like that would never get made.

Thanks so much for the feedback! I am actually really tired with these acrobats... I am pretty ok with the "easy" solution but only under the conditions that this is not a hardware fault. It's not a cheap device for me.

Also, if it turns out to be a firmware problem, I would be happy that I could help improve the system with these funny efforts.

I don't really think it's because of some third-party software I installed since, from the log, I can see that this problem happens when I got the brand new MacBook and brought it into the office. I actually didn't install much stuff except the coconut battery. And also, all the software I installed is pretty common. The only thing that is very susceptible is Logitech option+, but it seems not that related to it based on my experiments.

Yes. The best attempt is to wipe everything out. Well, let me make some mental preparation before doing that.

zztea wrote:

After a tons of struggle, I finally pinpointed the issue!!!

In short, the most likely cause is a conflict in the N1 Bluetooth controller’s low-power state. When the paired Logitech MX Master 3S is turned off, macOS leaves the controller in an automatic reconnection state while the Mac is asleep. In the office environment, a nearby device—in my case, a Zoom Room system—broadcasts a specific BLE advertisement that appears to be incorrectly matched by the controller’s reconnection or filtering rules, causing it to wake the Mac. After each wake, macOS restores the same reconnection state, allowing the nearby signal to trigger another wake and create a continuous loop.

For now, the most effective workaround appears to be the same one suggested by @flash608: turning off Bluetooth before closing the lid. Hopefully, Apple will address this issue in a future update.

<Bluetooth DarkWake Loop Bug Report.log>

Good job persevering & discovering the item triggering the issue for you. I know from personal experience it can be very difficult to do. It can take a lot of investigative work on the part of the user.....or if the user is not up to the task, then it is necessary to hire an expert to come in to figure it out on their behalf.

I also know some of Apple's AirDrop & Bluetooth implementations have a lot wrong and cannot be properly managed to better filter out items we wish to see and those we don't want to see. I've been hounded by requests with unknown Bluetooth devices and from others and also overwhelmed by the destination choices for AirDrop....cannot always tell my own devices apart. It would be nice if Apple would concentrate on these types of things.

I'm still getting a DarkWake after turning off Bluetooth (and wifi), so while that may be the issue for others it doesn't seem to be the problem for me. Is anyone else still seeing this problem after turning off Bluetooth?

MeetchK wrote:

I'm still getting a DarkWake after turning off Bluetooth (and wifi), so while that may be the issue for others it doesn't seem to be the problem for me. Is anyone else still seeing this problem after turning off Bluetooth?

In that case, the solution that worked for others is not the answer for you and you have a different issue. Any number of items that are installed can result in background activity that could drain the battery. Because your issue is different, you should start a new separate post/thread. Meanwhile, simply connect to the charger if one is available.

zztea wrote:

As long as a Logitech MX Master mouse is paired with the MacBook, this DarkWake issue occurs in signal-heavy environments—regardless of whether the mouse is turned on, off, or completely out of range. It appears to be a pairing bug with the N1 chipset.

If the LogiTech MX Master Mouse is unpaired and its software is completely uninstalled, does the issue still persist? If the issue no longer persists, then it's not clear to me if the root cause is the LogiTech software/drivers versus the N1 chipset.

Note that the M5 series is the first to officially use the N1 chipset, so this bug currently only affects a small subset of users. However, as more new devices are released, this issue will inevitably become more widespread. I genuinely hope Apple takes this seriously.

Scores of M5 devices have been sold and are being used and M6 devices are soon on the horizon. If M5 devices work fine without the LogiTech device installed and paired, then that might implicate the third party device/software. There have been other issues reported with the LogiTech mouse; it is a great product with many nice features, but it comes with complexity and its integration with the macOS seems maybe a bit fragile.

Also, they haven't been really able to pinpoint the issue, and they have been blaming it on external applications, Chrome, maybe even Logitech, and also on some bug. It's kind of weird that Apple has not been able to pinpoint this issue.