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; your disk is kept on that machine, and so is your GPU slot unless the platform released it — the balance reached zero, or a payment dispute froze payments | 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, or finished on its own. 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), error |
running | stopping, destroying | stopped, error |
stopping | destroying | stopped, running (stop never confirmed), error |
stopped | starting, destroying | running, error (the container is gone) |
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 — for an instance whose GPUs were released, a refusal usually means another renter has them now (gpus_unavailable). A stopped instance whose container disappears from its machine moves to error (workload_gone), because nothing is left to start. error_code on the instance names what happened, and the instance page explains it.
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.