Skip to content

Maintenance, reboot and power off

Scheduled maintenance hurts your reliability score far less than sudden downtime. A machine that disappears mid-rental is a failed rental; a machine that announced a window is a machine doing housekeeping.

Announcing a window does three things:

  • turns listing availability off for its duration,
  • pauses new rentals 2 hours before it starts, so you are not handed a fresh 6-hour booking 10 minutes before you pull the machine,
  • notifies clients.

Running rentals are allowed to finish. Automation leaves the machine alone.

You give the window a start, an end, a category — gpu, power, internet, disk, software, other — and a reason that clients see. Write the reason as something a renter can act on: “Replacing thermal pads on GPU 3 and 6” beats “maintenance”.

What happens: everything running on the machine stops. Telemetry resumes when it comes back.

Afterwards: the host comes back on its own. The agent starts with the system and reports again within a couple of minutes.

Because a reboot breaks the connection by design, the machine confirms the command completed on its first reconnect rather than immediately. The panel allows up to 15 minutes for that.

What happens: everything stops and the host powers down. It stays off until someone turns it on.

What happens: the GPUs go down and the host usually reboots.

This is the operation the installer deliberately refuses to perform, because it turns adding monitoring into restarting a server. From the panel it is an explicit choice with up to 30 minutes to complete.

Reboot, power off and driver update are refused while a machine is earning or about to. The refusal names the machine and what to do:

  • Rented on Vast.ai — wait for the rental to end, or stop it on the marketplace first.
  • In search on Clore.ai — take the machine out of search first, then come back.

This is enforced by the server, not by the button. A script or an assistant calling the API hits the same refusal, because a guard that lives only in the interface is not a guard.

Destructive actions ask twice, and the two questions are different on purpose:

  1. What will happen — the effect and the recovery, in plain words.
  2. Which machine — you confirm the name.

The second exists because the first is the one people learn to click through.