Mac Battery Draining Overnight, Lid Closed? What’s Actually Waking It

You close the lid at 100% and open it in the morning at 74%. The battery feels fine all day, so what happened overnight? Almost always: the Mac wasn’t really asleep — something kept waking it. Here’s what’s normal, what isn’t, and how to read the exact reason with tools already on your Mac.

By CoreGuard · Jul 7, 2026 · 12 min read

It’s a specific kind of annoying: the Mac was closed, doing nothing, and still bled a third of its charge. The temptation is to blame the battery. Usually the battery is fine — the Mac just wasn’t as asleep as you thought. macOS sleep isn’t a light switch; a sleeping Mac still wakes briefly, on purpose, to do background housekeeping, and sometimes something makes it wake far too often (or never really settle). The good news is that macOS logs every wake and every reason, so this is one of the most diagnosable problems on the machine — no guessing, no cleaner app.

Why does my Mac lose battery overnight with the lid closed?

Short version: it usually wasn’t fully asleep. Something kept waking it — a network wake, a connected accessory, a Bluetooth device, or an app holding a “don’t sleep” assertion — so it did small bursts of work through the night, and each one cost a little charge. A percent or two of loss is normal self-discharge; a big overnight drop almost always means repeated wakes, not a failing battery — and macOS logs the exact reason, so you can read it and calm it.

First: some overnight drain is normal

Before you troubleshoot, calibrate. Per Apple, when a Mac sleeps it is “still turned on, but it consumes much less energy” — so a small overnight drop is expected, not a defect. On Apple Silicon, a healthy MacBook with nothing connected typically loses only a percent or two over a night, and it’s often near zero (these are widely reported community figures, not an official Apple number — your mileage varies by model, macOS version, and what’s enabled). If you’re losing a couple of percent, stop here: that’s ordinary self-discharge.

This article is for the other case — waking to find 15%, 30%, 40% gone. That’s not self-discharge; that’s the Mac being woken, repeatedly, through the night. So the real question isn’t “is my battery bad?” It’s “what kept waking it?” — and that has a readable answer.

The big caveat: Apple Silicon sleeps differently

Most overnight-drain advice online is quietly wrong now, because it was written for Intel Macs. If you have an Apple Silicon Mac (M1 and later), three things are different, and they matter:

• There is no SMC to reset. Power management is built into the chip, so the classic “reset the SMC to fix sleep” step simply doesn’t exist — there’s no key combo. The legitimate equivalent is a full shut down → wait ~30 seconds → power on.
• The Intel hibernate/standby knobs are vestigial. Run pmset -g and you’ll still see hibernatemode 3 and a sleepimage file — but on Apple Silicon the old standbydelay/standby timers aren’t user-tunable, and (as Howard Oakley measured directly) settings like lidwake have “no effect at all” on M-series sleep. The Mac holds memory in an ultra-low-power state and only truly hibernates when the battery gets genuinely low — automatically, not on a timer you set.
• “Power Nap” is mostly a “Wake for network access” setting now. Apple’s labeled “Enable Power Nap” toggle is documented as Intel/desktop; on Apple-Silicon laptops the equivalent behavior lives under Wake for network access (more on that below).

The practical upshot: on a modern Mac, don’t chase sleep modes. The drain is almost always caused by wakes — and wakes are exactly what you can read.

What actually wakes a closed Mac

Here are the real causes, roughly in order of how often they’re the answer. Each is a legitimate thing macOS does — the problem is when one happens too much.

• Wake for network access. The Mac wakes briefly to keep network connections alive and stay reachable for shared services (file/printer/screen sharing, AirPlay) and for Find My to report its location. On a personal laptop this is the most common source of pointless overnight wakes. Setting lives in System Settings › Battery › Options: Always / Only on Power Adapter / Never.
• Something plugged into a port. The most under-appreciated cause. Apple states plainly that “if another device is connected to your MacBook when it’s… in sleep… the device’s battery may drain.” A USB-C hub, an Ethernet or HDMI adapter, an SD card, even a dongle with nothing attached to it, can hold the Mac partially awake or just draw power. Users routinely report an adapter alone costing ~1% per hour.
• Bluetooth devices. A paired mouse, keyboard, or headphones can wake the Mac when it’s bumped, and bluetoothd can hold a sleep-preventing assertion. If a wireless device is nearby and twitchy, it’s a prime suspect.
• An app holding a sleep assertion. Any app can tell macOS “don’t idle-sleep” — media players, downloads, backups, virtualization, screen-sharing. This is the classic “my Mac never really sleeps” case, and it’s the most directly readable of all (next section).
• Scheduled maintenance / Power Nap (Intel). On Intel Macs, Power Nap periodically wakes to check Mail, update Calendar and iCloud, and — when plugged in — download updates and run Time Machine. Spotlight re-indexing after a big update, or Photos/iCloud sync, can also keep a Mac busy through the night.

Read the exact reason with built-in tools

This is the part that turns guesswork into an answer. macOS ships a power-management tool, pmset, that tells you both what’s currently holding the Mac awake and why it woke in the past. Open Terminal (Applications › Utilities) and use these — they’re all read-only.

What’s keeping it awake right now: pmset -g assertions

This is the single most useful command. It prints the system-wide assertion states, then — crucially — names the process holding each one. An abridged example:

$ pmset -g assertions
Assertion status system-wide:
   PreventUserIdleSystemSleep     1
   PreventSystemSleep             0
   PreventUserIdleDisplaySleep    0
   NetworkClientActive            0
Listed by owning process:
   pid 771(Music): [0x...] PreventUserIdleSystemSleep named: "com.apple.Music is playing"
Kernel Assertions: 0x100=MAGICWAKE
   id=558  0x100=MAGICWAKE owner=en0   (wake for network)

Read it top to bottom. A 1 next to PreventUserIdleSystemSleep means something is stopping the Mac from idling to sleep; the “Listed by owning process” block tells you exactly which app (here, Music, because a track was left playing) and often why. That’s your culprit — quit it and run the command again to confirm the 1 flips to 0. The MAGICWAKE kernel assertion, if present, is “wake for network access” on your network interface.

Why it woke overnight: pmset -g log

To see the history — every sleep and wake, with a reason — use the log. It’s verbose, so filter it:

pmset -g log | grep -e "Wake" -e "Sleep" -e "DarkWake"

Each wake line carries a reason code. You don’t need to memorize them — the reliable move is to correlate the timestamp with what was connected or running — but a few are worth recognizing:

Prefer a window to a Terminal? Activity Monitor

If Terminal isn’t your thing, open Activity Monitor, click the Energy tab, and turn on the “Preventing Sleep” column (View › Columns). Any process showing “Yes” is currently blocking sleep — the same information as pmset -g assertions, in a list you can sort. It’s the friendly version of the same answer.

How to calm it — safely, no deleting

Once you know the cause, the fixes are simple, reversible, and don’t touch a single system file. Change one thing at a time and measure the next night — that’s how you actually confirm what helped.

• Set “Wake for network access” to Never or Only on Power Adapter (System Settings › Battery › Options). The honest trade-off: while it’s asleep on battery, Find My location updates and shared-service access pause — fine for most personal laptops, worth knowing.
• Unplug accessories and hubs before closing the lid on battery. Test one night with nothing attached; if the drain vanishes, add things back one at a time to find the offender.
• Quit the app you found holding the assertion. Don’t guess — act on what pmset -g assertions named.
• Turn off Bluetooth overnight if a wireless device is the trigger (confirm with the log first).
• On Intel Macs, disable Power Nap if you don’t need overnight Mail and backups.
• If it’s still stuck on Apple Silicon, do the full shut down → wait ~30s → power on. That’s the legitimate stand-in for the SMC reset those Macs don’t have.

One thing that isn’t a problem: if your Mac sits at 80% while plugged in, that’s Optimized Battery Charging working as designed to reduce wear — a health feature, not a failure to charge. If it’s the daytime drain that’s bothering you rather than overnight, that’s a different hunt — the process kind — and we walked through it in “your battery didn’t age overnight.”

What not to do

The search results for this problem are a museum of outdated advice. Skip these:

• Don’t “reset the SMC” on an Apple Silicon Mac. There isn’t one. It’s Intel-era advice that can’t apply.
• Don’t delete /var/vm/sleepimage or force hibernatemode 25. On Apple Silicon it does nothing useful; everywhere it trades normal fast-wake sleep for slow full-hibernation, for negligible gain.
• Don’t run a “battery saver,” “cleaner,” or “optimizer” app to fix it. The drain is a readable wake reason, not junk to clean — and no app can cleanly override a macOS sleep assertion for you.
• Don’t copy pmset standby tweaks from old blogs. Most are Intel-only and silently ignored on Apple Silicon.
• Don’t panic over one or two percent — that’s normal self-discharge, not a battery fault, and no honest tool would pretend otherwise.

Where CoreGuard fits

Reading pmset -g log at 8 a.m. is a chore, and that’s the gap CoreGuard is built for. It watches the same signals macOS already exposes — what woke the Mac, which process is holding a sleep assertion, and how the battery actually moved overnight — and shows them in plain English with a history, so instead of grepping a log you just see “the Mac woke 40 times last night; Music was holding a sleep assertion.” The live readings, the “what woke your Mac” and sleep-assertion view, and every danger or health warning are free, forever; the deeper trend history and the exportable report are Pro.

And the boundary, as always: CoreGuard observes and explains — it never invents a fake verdict, never predicts a failure date, and never cleans, optimizes, speeds up, or “boosts” your battery. It won’t hand you a scary battery-health verdict, it isn’t an antivirus, and it won’t override macOS’s sleep behavior behind your back — it shows you the wake reason and hands you the built-in setting to change. It’s local-only too: zero network connections, verifiable with lsof -i -nP | grep CoreGuard.

CoreGuard isn’t out yet — the download and checkout go live shortly. Free covers the live readings, the “what woke your Mac” and sleep-assertion view, and every danger warning, forever; Pro adds the deeper trend history and the exportable report, and is a one-time $29 (Family $49), perpetual, not a subscription, with a 30-day money-back guarantee. If you want the overnight story without the Terminal, get notified and grab it free at launch, or see what Pro adds. Either way — when you wake to a drained Mac, read the wake reason before you blame the battery.

Frequently asked questions