Lifecycle and states

A lifecycle request owns an operation and a physical transition. Running, ready and busy are distinct observations. Keep both the old and the superseding operation IDs when requests compete; the earlier operation can fail even though later work succeeds.

States

States: creating, starting, running, pausing, paused, resuming, stopping, stopped, restarting, resizing, restoring, suspended, error, deleting, deleted.

A deleting computer remains readable with 200 and stays in lists until deletion completes. Only deleted computers return 410 for 30 days, then 404.

• ready means the in-guest agent answers through the gateway. Billing never depends on readiness.
• busy: "snapshot" while a snapshot is being taken; the computer keeps its state and is billed as that state.
• state_reason: timeout, low_balance, spend_limit, host_restart, host_memory_pressure, platform_freeze, abuse_review, memory_discarded_after_30_days, guest_shutdown.
• During the 7-day zero-balance quarantine a computer is suspended with state_reason low_balance and scheduled_deletion_at set to the purge time. It becomes deleted, and computer.deleted is emitted, only at purge.

After a top-up during retention. A credited top-up first repays any negative posted funds. If available balance is still not positive, the retention timeline continues and nothing is restored. If available balance becomes positive, pending low-balance deletion is cancelled, quarantined files are recovered, and only the low-balance restriction is cleared. Quarantined computers recover stopped; others remain paused if saved memory exists, otherwise stopped. Independent restrictions (for example abuse review or a spend limit) remain in force and may keep the public state suspended. No computer starts or resumes automatically.

Always-on slots. An always-on computer whose slot was released keeps mode=always_on but is not automatically re-reserved. It accrues neither always-on nor own-storage charges until a successful explicit start or resume, or a successful PATCH to on_demand. An explicit start or resume must satisfy current restrictions and balance admission and acquires a fresh reservation; unavailable capacity returns 503 capacity_unavailable. No back-charge is made for unreserved time.

Transition table (202 = accepted async; 200 = no-op; 409 = invalid_state):

Acceptance of stop or delete is not immediate physical completion, and a superseded operation can never restart a computer later. A legal hold turns a restore or delete that would destroy held data into 409 invalid_state. Stop and pause are not refused solely because of a hold. A stop from paused still ends stopped, with normal stopped billing and no resumable memory.

Resize changes CPU, RAM and size, not the provisioned disk capacity. disk_gb continues to report that capacity; a resize never shrinks or enlarges the virtual disk or guest filesystem. A same-size request is a 200 no-op. Existing snapshots may remain, but restore requires a matching configuration. Tier, key limit, policy and the target size's reservation are checked before the resize starts. On success the new size takes effect and the higher monthly cap starts from that moment. On failure the old size and cap history stay and the old CPU and RAM are restored; if the rollback cannot be verified, the computer stays off in error until it is reconciled, and cannot be started until it is consistent again.

A higher monthly cap applies only from the end of a resize. Earlier time is never back-charged; the existing monthly counter carries forward.

Timer and mode changes

See Computers for the exact rules for PATCH, extend, timeout_seconds, on_timeout and mode.

Operation ownership

Delete supersedes unfinished lifecycle work; stop supersedes unfinished boot or restart work. A superseded operation ends failed with invalid_state, status 409, retryable: false, finished_at set and the detail "Superseded by a newer lifecycle request". Effects that already happened may not be cancellable; newer work waits for a safe point. Poll both operation IDs and do not retry the superseded start under a fresh key.

An operation's completion, the verified final state and its event are committed together. A snapshot can leave the state running with busy set to snapshot; conflicting changes must wait or are refused. A local waiter timeout does not cancel the accepted operation. See Operations.

Safety work and held data

Pauses for low balance, spend limits and timeouts are retried with capped backoff. Low-balance enforcement can fall back to stop after repeated refusal; spend-limit pauses do not fall back to stop. A legal hold prevents destructive acceptance when held data would be destroyed: the response is 409 invalid_state with retryable: false, and no billing change follows. Non-destructive pause and stop remain subject to the table above. No hold-release date is promised.

Dory is in development; these pages describe the planned service and may change. Questions: support@computeengines.com.