In this article
Maintenance ends when the agreed checks pass, not merely when the machine powers on again.
A Vast.ai host maintenance window should cover stopping work, making the agreed change and checking the result. Before touching the machine, review active workloads and platform procedures. Record when the node is expected to become ready again, rather than only when it will be switched off.
The same structure works for a software update, component investigation or planned site interruption. It supports a reviewable maintenance plan without assuming that any current workload can be interrupted.
Define the change and its boundary
Describe a specific action, such as checking a storage component. List the parts of the environment that should remain unchanged. Combining a small repair with an unrelated upgrade makes a later problem harder to diagnose.
Vast.ai’s maintenance command documentation describes start time, duration and maintenance categories. The existence of a notification command does not make every interruption suitable for every active rental. Check the applicable conditions before scheduling the work.
Separate planned and actual times
Record planned start, expected completion and time zone. After the work, add actual shutdown, completion of the change and return to readiness. A powered-on machine may still be loading services or recovering its working environment.
When a site uses local time, retain an unambiguous UTC representation as well. Keep a version history if the window changes so the owner and operator do not act on different messages. A correct duration still fails as a plan if the participants interpret its start differently.
Agree on evidence of completion
The acceptance check might cover device visibility, known errors, environment availability and a small control task. NVIDIA DCGM Health Monitoring describes passive observation, which differs from an active diagnostic workload. An absence of warnings does not establish that every possible stress test has passed.
| Field | Example content |
|---|---|
| Reason | Check one identified component |
| Start condition | Workload completed or interruption agreed |
| Schedule | Start, UTC and estimated duration |
| Change | Action or version recorded |
| Verification | Named check and observed outcome |
| Readiness | Time and responsible person |
This is a suggested maintenance card. Preserve marketplace messages separately if they disagree with the local log, then investigate the difference instead of overwriting the inconvenient record.
Plan for unfinished work
Identify a contact, a way to update status and a condition for restoring the previous configuration where restoration is possible. Define these before the maintenance period starts. Unexpected extra time should result in an explicit status update and decision.
Do not turn planned downtime into invented lost revenue. Record actual availability and any separately agreed accounting method. They help define a practical pilot before a workload is selected.
Continue with Vast.ai Offer End Date: Plan When Your Server Must Return and A Change Register for GPU Drivers and Server Settings.