Operations
Track asynchronous changes, cancellation, reconciliation, and partial completion.
Operations record the execution of infrastructure changes. An operation links the initiating request to validation, resource changes, component events, cleanup, and its final outcome.
Operation states
Open Operations → Queue for active work or Operations → History for completed changes. A resource's Operations tab filters the same records to that resource ID.
An accepted operation begins Queued and becomes Running when a worker applies the change. Reconciling means the outcome of an issued step cannot be established from authoritative component state. It does not mean the step can safely be issued again.
Cancellation passes through Canceling while active work is brought to a consistent boundary. Succeeded, Failed, and Canceled are terminal results. Each can contain completed steps and retained resources that need to be interpreted according to the operation type.
Recover ambiguous operations describes interrupted execution. The Operation API lists machine-readable states and result fields.
After an infrastructure operation succeeds, test the affected application before restoring traffic. The operation result covers infrastructure changes, not application readiness.
Read an operation
Open Operations or follow the operation link on a resource. The details include actor, request ID, target IDs, requested revision, phase, timestamps, progress, child operations, and errors. The journal lists component observations used to determine the result.
Progress describes the active phase. A byte counter, resource count, or percentage does not guarantee an estimated finish time. A repeated transfer or retry can change the amount of work remaining.
Resource locks
Conflicting actions hold a resource lock while their operation is active. A migration blocks resize and delete on the same droplet. Reading state and metrics does not require the write lock.
A rejected action returns operation_conflict and the blocking operation ID.
Open that operation under Operations → Queue. If it is progressing, wait for
its result. If it should stop, follow Cancellation. If its
journal reports a dependency failure, correct that condition before retrying
the original action. A competing action does not clear the lock.
Cancellation
Open Operations → Queue, select the operation, and check cancelable.
If it is true, select Cancel and follow the transition through Canceling
to Succeeded, Failed, or Canceled. The result can be Succeeded if execution
finished before cancellation took effect.
If cancelable is false, the current phase cannot be interrupted. Follow the
operation journal until the result is established. For an operation stuck in
Reconciling, use operation recovery before retrying or
starting a replacement.
Canceling a parent plan prevents new child work. Children already running can finish. A completed migration is not moved back and a completed disk expansion is not shrunk. The terminal result lists these partial changes.
Reconciliation after disconnection
If a request reaches a node but its response is lost, Infra queries authoritative state before deciding whether to retry. An operation remains Reconciling while that state is unavailable. Operation recovery describes which evidence resolves an interrupted step. A browser timeout does not cancel it.
For API requests, reuse the idempotency key and read the returned operation ID. Starting a new request with another key can create a second intended resource after connectivity returns.
Recovery and retention
Failed operations identify retryable errors, completed work, and retained resources. Retry only after the condition has changed or the response permits a bounded retry. Authentication, validation, and policy failures require a configuration correction.
Operation summaries follow installation retention policy. Related audit records have their own retention. Export both for an investigation that must outlive the configured history.