How to wake a Mac for a scheduled job with pmset

The command

sudo pmset schedule wake "08/21/2026 02:58:30"

The format is MM/dd/yyyy HH:mm:ss, 24-hour, seconds required. To see what is armed:

pmset -g sched

And to remove it:

sudo pmset schedule cancel wake "08/21/2026 02:58:30"

Note that cancelling requires the *exact* time you scheduled. This is the first thing that trips people up: a stale entry you can no longer remember the timestamp of has to be cleared with pmset schedule cancelall, which takes out everything, including any wake macOS itself arranged.

Why waking is only half of it

A Mac that wakes with nothing to do goes back to sleep. The scheduled wake gets you a machine that is powered up at 02:58:30; it does not get you a machine that is still powered up at 03:00:45 when your backup is halfway through writing a tarball.

So the real recipe is two things, not one:

# arm the wake, 90 seconds before the job is due
sudo pmset schedule wake "08/21/2026 02:58:30"

# and in the job itself, hold sleep off while it runs
caffeinate -s /usr/local/bin/nightly-backup

caffeinate -s prevents system sleep for the lifetime of the command it wraps and releases when the command exits, which is the correct shape: the hold lasts exactly as long as the work.

With the lid open, on mains, that combination works. There are four ways it comes apart.

The four things that go wrong

1. The wake is consumed

A one-shot scheduled wake fires once and is gone. Tomorrow's 03:00 job has no wake armed for it unless something armed one. For a recurring job this means the job itself has to schedule its own next wake as its last act — and if a run fails before reaching that line, the chain is broken silently and permanently.

pmset repeat exists for recurring events, but pmset(1) is explicit about its limit: *"you may only have one pair of repeating events scheduled — a 'power on' event and a 'power off' event."* One pair, for the whole machine. Two jobs on different schedules cannot both use it, and neither can you and macOS.

2. The schedule is shared with the rest of the system

Multiple wakes do coexist — they are tagged by owner, and a normal Mac has several at any moment. Here is a real pmset -g sched:

[0]  wake at 08/20/2026 13:39:40 by 'goguma'
[1]  wake at 08/20/2026 16:58:29 by 'com.apple.alarm...travelEngine.periodicRefreshTimer'
[2]  wake at 08/21/2026 00:00:00 by 'com.apple.alarm...ScheduleLifetimeMonitor.timer'
[3]  wake at 08/21/2026 01:43:49 by 'com.apple.alarm...acmd.alarm'

The hazard is not collision, it is cleanup. Cancelling requires the exact type and timestamp you scheduled, so a stale entry whose time you no longer remember cannot be removed individually. The blunt instrument is pmset schedule cancelall, which takes out everything — including the three Apple entries above, which the system put there for its own reasons and will not necessarily replace.

3. caffeinate does not survive the lid closing

This is the big one for laptops. caffeinate asserts against *idle* sleep. Closing the lid triggers clamshell sleep, a lower-level path that the assertion does not touch. On a closed MacBook with no external display and no mains power, the machine sleeps and takes your job with it. Covered properly in why caffeinate doesn't work with the lid closed.

The mechanism that does hold a closed lid awake is sudo pmset -a disablesleep 1 — and that one has its own serious problem: it is a global setting that persists in the power management preferences and is not cleared when the process that set it dies. Anything that sets it and is then killed leaves a Mac that cannot sleep at all until someone notices.

4. Waking a flat battery is worse than not waking

This is the one almost nobody accounts for, and it is worth thinking through carefully.

Suppose your Mac is on battery at 11% and a job is due at 03:00. You wake it. The wake itself costs charge. The job runs, costs more. If you have a safety cutoff that releases the hold at 10%, it fires almost immediately — so you have spent energy on a wake, not completed the job, and arrived closer to a hard shutdown than if you had done nothing at all.

A safety cutoff cannot un-wake a machine. By the time it fires, the energy is already spent. Which means the check has to happen *before* the wake is armed, not after it fires — and the margin should be the job's own measured cost, not a flat number. Refusing to wake at 24% for a job that has historically used 0.5% of the battery protects nobody from anything.

What this looks like automated

Doing all of the above by hand, per job, and keeping it correct as schedules change, is more work than most jobs are worth. Automated, the pieces are:

• Read the jobs already on the machine — crontab, launchd, whatever else — rather than asking you to redeclare them
• Compute the next fire time and arm a wake 90 seconds before it, which is enough for the machine to be up and settled
• Hold sleep off from the wake until the job exits, using a mechanism that survives a closed lid
• Learn how long each job actually takes, so the hold fits the work instead of a guess
• Skip launchd's StartCalendarInterval jobs, which re-fire on wake by themselves and need no help
• Re-arm after every fire, so the chain never depends on a job succeeding
• Refuse the wake when the battery cannot afford it, using that job's own measured drain as the margin
• Release everything if a closed-lid machine gets hot or the charge falls

That list is what goguma is. Each item is small; the reason to use a tool is that all eight have to be right at once, forever, and a mistake in any of them is silent.

Common questions

What is the command to wake a Mac at a specific time?

sudo pmset schedule wake "08/21/2026 02:58:30" — the date format is MM/dd/yyyy and the time is 24-hour with seconds. Use pmset -g sched to see what is currently armed.

Does the Mac stay awake after a scheduled wake?

No. It wakes, finds no reason to stay up, and returns to sleep after the normal idle timeout — often before a job has finished. You need caffeinate or a sleep block to hold it for the duration of the work.

Do I need to re-arm the wake after it fires?

Yes. A one-shot scheduled wake is consumed when it happens. For a recurring job you must arm the next occurrence each time, which is the part that makes the manual approach impractical to maintain.

Does pmset schedule work with the lid closed?

The wake itself does. Staying awake afterwards is the harder half — a closed lid on battery with no external display takes a different sleep path that caffeinate cannot hold off.

Does this work if the Mac is powered off?

pmset schedule poweron can power a Mac on from off on machines that support it, but it is a much blunter instrument and behaves inconsistently across models. Wake-from-sleep is the reliable case.