# Instance lifecycle

The eight statuses an instance moves through from launch to termination, what changes each one, what you're billed for, and what FAILED means.

An instance’s status is always one of eight values. Four of them are transitional and resolve on their own. `RUNNING`, `STOPPED` and `FAILED` change only when something asks for a change, and `TERMINATED` is final. Every lifecycle operation is asynchronous: the call returns once the platform accepts the request, and `status` tells you what happened.

The following diagram shows every transition you can observe.

<Diagram
  name="instance-lifecycle"
  alt="Every transition between the eight instance statuses"
/>

You can also terminate an instance that is `INITIALIZING`, `PENDING` or `STOPPING`. The diagram leaves those edges out to stay readable.

## Statuses [#statuses]

`status` is a typed enum in the API. A client generated from the schema gets the full set, so compare against the enum rather than against strings you’ve seen in a response.

| `status` | What it means | Compute billed |
| --- | --- | --- |
| <Status value="INITIALIZING" /> | Just launched. Its root disk and network interface are being created. Not running, not reachable. Moves on by itself. | No |
| <Status value="PENDING" /> | Everything it needs is ready and the platform has asked its host to start it. Moves on by itself. | No |
| <Status value="RUNNING" /> | The host confirmed the instance started. | Yes |
| <Status value="STOPPING" /> | A stop was requested. The guest may still be running until it shuts down. Moves on by itself. | No |
| <Status value="STOPPED" /> | Not running, but still yours. Its network interface stays reserved and its volumes stay attached. You can start it again. | No |
| <Status value="SHUTTING_DOWN" /> | A termination was requested. The guest is being shut down if it was running, and the instance’s resources are being released. Moves on by itself. | No |
| <Status value="TERMINATED" /> | Permanently gone, and the resources it held are released. Nothing leaves this status. | No |
| <Status value="FAILED" /> | The host didn’t do what it was asked, or something the instance needs could not be created. Always carries a `statusReason`. | No |

Compute usage stops being metered as soon as the instance leaves `RUNNING`. Volumes are billed separately for as long as they exist, so a `STOPPED` instance’s root disk is still billed. For storage billing, see [Volumes](/docs/storage/volumes).

## Changes nobody asked the platform for [#changes-nobody-asked-the-platform-for]

Two transitions happen without a stop request:

- Guest power-off. When you shut the operating system down from inside the guest (`poweroff`, `shutdown -h`), the instance goes from `RUNNING` straight to `STOPPED`, without `STOPPING`. Its `statusReason` stays `null`. Start it again the usual way.
- Machine failure. When the platform can prove the machine under a running instance failed, it records the instance as `STOPPED` with a `statusReason` that says so. For details, see [When the machine under an instance fails](/docs/compute/instances/host-failure).

## Polling [#polling]

Poll through the transitional statuses: `INITIALIZING`, `PENDING`, `STOPPING` and `SHUTTING_DOWN`. Stop polling when the instance reaches `RUNNING`, `STOPPED`, `FAILED` or `TERMINATED`.

`RUNNING` means the host confirmed the start. It doesn’t prove the guest’s operating system and network are up. To know that, read the instance’s health checks. For more information, see [Instance health checks](/docs/compute/instances/health-checks).

## When a lifecycle operation fails [#when-a-lifecycle-operation-fails]

If the host can’t carry out a start or a stop, the instance ends up `FAILED`. It never stays in a transitional status waiting for something that isn’t coming. `FAILED` means one thing: the platform can’t confirm the instance is where you asked it to be. It doesn’t promise that the guest is stopped or gone.

The common cases:

- A launch or start that failed. The host refused the start, or a volume or network interface the instance needs could not be created or attached. `statusReason` says which.
- A stop that failed. The guest may still be running.
- An operation the host never confirmed. If the instance’s host is reachable but doesn’t confirm a start or a stop, the platform sends the request again, three times in total, about 10 minutes apart. An instance can therefore sit in `PENDING`, `STOPPING` or `SHUTTING_DOWN` for about 30 minutes before it becomes `FAILED`, with a `statusReason` saying the host did not confirm.

A `FAILED` instance keeps its network interface and volumes, stays listed, and never retries on its own. You have two ways forward:

- Start it. `start-instance` moves it to `PENDING` and back into the normal lifecycle. There is no separate “retry the stop”: start it, then stop it again.
- Terminate it. Terminating a `FAILED` instance doesn’t wait for its host to confirm the guest is gone, because the host may not answer at all. The platform releases the instance’s resources, stops billing and reports `TERMINATED`.

A `FAILED` instance can still hold capacity on its host, and you can’t change its type. Don’t leave one sitting indefinitely. Every possible `statusReason` is listed in [Status reasons](/docs/compute/reference/status-reasons).

## Terminated instances [#terminated-instances]

A terminated instance stays in `list-instances` for 2 hours after it terminates, then drops out of the default list. You can still read it by its URN with `get-instance`, however long ago it terminated.

## Related [#related]

- [Stop and start an instance](/docs/compute/instances/stop-start)
- [Terminate an instance](/docs/compute/instances/terminate)
- [Status reasons](/docs/compute/reference/status-reasons)
- [Troubleshoot Compute](/docs/compute/troubleshooting)