Wake a fleet for a patch window, and reboot it afterwards
The point of a fleet that sleeps overnight is that it costs nothing overnight. The price of it is that updates land on machines that are switched off, which leaves the two bad options everybody knows: patch during the working day and interrupt people, or send somebody round the floor pressing power buttons at seven in the morning.
Waking a fleet on a schedule, letting the updates run, restarting the machines and putting them back to sleep is the oldest legitimate use of Wake-on-LAN there is. This guide covers doing it so that it survives contact with reality — machines that do not come up, more than one subnet, and somebody eventually asking for evidence that it happened.
The window, end to end
The shape of a maintenance window is the same everywhere. Wake the machines shortly before the window opens; let whatever manages your updates do its work; restart the ones that need it; put them back to sleep before the working day starts. Each of those four is a scheduled action rather than a person, or it will not happen reliably.
In Rooster Wake the schedules live server-side rather than on somebody's laptop, they retry, and every firing lands in the account's history whether it succeeded or not. Both directions are covered by one mechanism: a schedule can wake a machine at 02:00 and another can sleep it at 05:30. Schedules are on the paid plans — ten of them on Plus, unlimited on Pro.
Restarting after the updates land
Waking is done by the network card and needs nothing installed. Restarting is the opposite: something on the machine has to ask the operating system to do it, which is what the agent is for. Install it and, on the Plus and Pro plans, you can restart, sleep or shut down that machine from the dashboard, the API or a schedule.
One piece of physics to design around: an agent cannot wake the machine it runs on, because a sleeping machine is not running anything. So the emitter that starts the fleet has to be something that stays awake — an agent on a server or a management box that never sleeps, or a dongle. The agent on each workstation is for the return trip.
More than one subnet
A magic packet is a broadcast and does not cross a router. If your machines sit on several VLANs or in several buildings, you need something awake on each segment — that is a property of the protocol, not a limitation of any product, and anybody claiming otherwise is describing a directed-broadcast configuration on your own routers rather than something they do.
The Pro plan covers five emitters, which is five segments, and machines are counted account-wide rather than per emitter — twenty of them included — so which emitter carries which machine is a topology detail rather than a pricing one. Additional emitters and machines can be added to a Pro plan as slots if the shape of your network needs it.
Doing a whole site at once
On the Pro plan machines carry a site label — Ground floor, Warehouse, Branch two — and the dashboard groups them by it, so a maintenance window is one action per site rather than one per machine. The batch controls run the same per-machine checks as pressing each button individually, one at a time, so nothing is bypassed by using them.
For anything that has to be driven from your own tooling instead, the REST API does everything the dashboard does. API keys are on the paid plans: five on Plus, unlimited on Pro. A key can be scoped so that the credential in your automation is allowed to wake machines and nothing else.
Knowing it worked, and proving it later
Wake-on-LAN has no acknowledgement, so a fleet wake with nothing watching it is a fleet wake you find out about from a user. Confirmation probes each machine after the packet goes out and records whether it came up, with the likely reason when it did not; failure alerts cover the case nobody was watching, which for a 02:00 window is every case — a scheduled wake that did not land, or an emitter that stopped reporting days before the window. Both are on the paid plans.
For a webhook into your own monitoring, the Pro plan carries up to twenty-five, so a failed wake can raise a ticket where your team actually looks. History retention is thirty days on Plus and twelve months on Pro, and the Pro plan can export the whole event history as a CSV file through the API — a stable, paged format for whatever ingests it, rather than a screenshot of a dashboard.
Getting the agent onto twenty machines
Installing the agent interactively works fine on one machine and does not scale to a floor of them, because the interactive install asks the person at the desk to confirm the account. The Pro plan's answer is an enrolment token: one reusable, revocable credential that binds every machine you install the agent on, with nobody signing in at each desk.
On Windows that makes the install a single silent line you can send through whatever you already use to distribute software — the Windows installer accepts ENROLTOKEN as a property and runs with /qn — and each machine appears on the dashboard as it enrols. Revoking the token stops it being usable for future installs without disturbing the machines already enrolled.
If the fleet is not the whole picture — one desktop to reach from home, a shared machine several people wake, a lab of your own — who uses Wake-on-LAN maps the six common ones and points at the guide for each.