Skip to content
Origin Cloud Docs

Compute / Concept

Instance lifecycle

Updated · 5 min read

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

On this page6 sections

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.

Instance lifecycle Launch creates an instance in INITIALIZING. When its resources are ready it moves to PENDING, and when the host confirms the start, to RUNNING. A stop moves RUNNING to STOPPING, and the host confirming the stop moves it to STOPPED. A guest power-off or a machine failure moves RUNNING straight to STOPPED. Start moves STOPPED or FAILED back to PENDING. INITIALIZING becomes FAILED when a resource is not created; PENDING when a start is refused or unconfirmed; STOPPING and SHUTTING_DOWN when a stop is refused or unconfirmed. Terminate moves RUNNING, STOPPED or FAILED to SHUTTING_DOWN, which ends in TERMINATED. billed INITIALIZING PENDING RUNNING STOPPING FAILED STOPPED SHUTTING_DOWN TERMINATED launch resources ready host confirms start stop host confirms stop guest power-off or machine failure start terminate terminate stop refused or unconfirmed stop refused or unconfirmed start refused or unconfirmed start resource not created terminate
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

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.

statusWhat it meansCompute billed
INITIALIZINGJust launched. Its root disk and network interface are being created. Not running, not reachable. Moves on by itself.No
PENDINGEverything it needs is ready and the platform has asked its host to start it. Moves on by itself.No
RUNNINGThe host confirmed the instance started.Yes
STOPPINGA stop was requested. The guest may still be running until it shuts down. Moves on by itself.No
STOPPEDNot running, but still yours. Its network interface stays reserved and its volumes stay attached. You can start it again.No
SHUTTING_DOWNA 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
TERMINATEDPermanently gone, and the resources it held are released. Nothing leaves this status.No
FAILEDThe 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.

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.

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.

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.

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.