Inspect before you schedule

The local pmset manual distinguishes one-time schedule events from repeating events and documents pmset -g sched as the view for scheduled startup/wake and shutdown/sleep events. It also says repeating schedules are limited to one pair: a power-on event and a power-off event. Read the existing state first, especially on a shared or managed Mac.

Hardware and current macOS policy determine what is practical. Apple’s System Settings guidance says some sleep and wake options are unavailable depending on the Mac. A command that parses on one machine is not a guarantee that it will produce the same behavior on another, particularly around powered-off wake capability.

pmset -g sched
pmset -g cap

Keep diagnosis separate from configuration

The command syntax for creating or cancelling events changes system behavior and can require administrator privileges. Do not use a borrowed schedule recipe to diagnose a drain issue. First establish whether an event is actually present and whether its time overlaps the symptom. For a regular work schedule, prefer an intentional, documented change followed by a real follow-up observation.

A relative wake event is not a precise timer, according to the local manual, and schedule behavior can be affected by system state. Do not build a safety-critical workflow around it. If an unexpected wake remains after schedules are ruled out, inspect network access, sharing, assertions, and the sleep log.

WattGuard does not schedule hardware wake

WattGuard can display sleep history and help compare an affected session with prior sessions. Its automations can run while the app is running, but it does not promise to schedule hardware wake. Use the app’s data to assess a change, not to assume that a schedule is supported on every Mac.

Sources

Explore WattGuard