Instance states
Every instance is in exactly one of eight states. The badge on the Instances page, the badge on the instance detail page, and the status field returned by the API all report the same value.
The states
| State | Transitional | What it means | What it bills | What you can do from it |
|---|---|---|---|---|
creating | yes | Your deploy was accepted and Superheat is provisioning the slice and pulling the image | nothing | Wait, or destroy |
starting | yes | A stopped instance is coming back on the same machine with the same disk | nothing | Wait, or destroy |
running | no | The workload is up and the connect details are published | GPU: the offer's hourly price for the whole slice, metered by the second | Connect over SSH, open JupyterLab, read logs, stop, destroy |
stopping | yes | The workload is shutting down; the disk is retained | nothing | Wait, or destroy |
stopped | no | The workload is down; the disk stays on the machine. The GPUs are held for you — unless the platform released them when the balance ran out, where the machine supports it | Disk: your disk size multiplied by the storage rate per GB-hour | Start, destroy |
destroying | yes | Teardown is in progress and the slice is being released | nothing | Wait. Destroying again re-sends the teardown |
destroyed | no | Terminal. The disk is deleted and the offer is back on the marketplace | nothing | Nothing. Destroyed instances are hidden from the list unless you ask for them |
error | no | The workload could not be brought up, failed or was lost, finished on its own, or its container disappeared while the instance was stopped. error_code says which | nothing | Read logs, destroy |
error bills nothing. Once the platform has seen the workload end — it failed, was lost, or finished — the GPUs are released and come back into the offer's available_units. A deploy that failed before its workload reached the host still holds them until the instance is destroyed. Every errored instance counts toward the 25-instance limit until it is destroyed.
Transitional states
Four states — creating, starting, stopping and destroying — are transitional: Superheat is completing the change, no meter is running, and nothing you do moves it along faster — though a creating, starting or stopping instance can be destroyed outright rather than waited on. The console draws a pulsing badge for these and polls every 3 seconds while any of your instances is in one, then falls back to every 15 seconds once everything has settled.
While an instance is creating, the console shows the hint Provisioning your machine…. A large image pull can keep it there for minutes, and none of the pull time is charged.
Which transitions are legal
| From | You can ask for | The platform can also move it to |
|---|---|---|
creating | destroying | running, error |
starting | destroying | running, stopped (resume refused or never confirmed, including when its released GPUs are taken or out of service), error |
running | stopping, destroying | stopped, error |
stopping | destroying | stopped, running (stop never confirmed), error |
stopped | starting, destroying | running, error (its container disappeared while stopped) |
destroying | — (asking again re-sends the teardown) | destroyed, error |
destroyed | nothing — the state is final | nothing |
error | destroying | running, stopped (the workload was found healthy) |
The normal path is creating → running → stopping → stopped → starting → running. Teardown is always destroying → destroyed.
destroying is reachable from every state that is still live, on purpose. A deploy that never lands — placement waiting forever because nothing in the fleet matches, or a job the host no longer knows about — or a stop or start the host never answers would otherwise leave an instance you cannot delete. You can destroy an instance that is still coming up, starting or stopping. A DELETE on an instance that is already destroying is not refused either: it asks for the teardown again.
The platform's own moves are there to keep the state honest. A stop the host does not confirm within 30 minutes puts the instance back in running — the container is still up, so the GPU meter goes back on — and the stop is retried. A start the host refuses, cannot be reached for, or does not confirm within 30 minutes puts it back in stopped. error_code on the instance names what happened, and the instance page explains it.
An instance whose GPUs were released cannot start while those GPUs are in use by someone else or out of service on that machine: either the request itself fails with 409 CAPACITY_UNAVAILABLE, or the instance goes to starting and back to stopped with error_code gpus_unavailable. An instance whose container disappeared from the machine while it was stopped moves to error with error_code workload_gone: there is nothing left to start, and destroying it is the only action.
Any request that asks for a transition outside the "You can ask for" column is refused with 409 INVALID_STATE and the instance is left alone. The API lists what is allowed right now in the instance's allowed_actions.