🧱 Pulumi Error: 'the stack has pending operations' After an Interrupted Update

Exact Error Message

error: the current deployment has 1 resource(s) with pending operations:
  * urn:pulumi:prod::app::aws:ec2/instance:Instance::web (creating)

These resources are in an unknown state because the Pulumi CLI was interrupted while
operating on them. To reset the stack's state, use `pulumi refresh` or the `pulumi
cancel` command as appropriate.

You may also see it phrased as (deleting) or (updating) in the pending list, and Pulumi refuses to continue any further up or destroy until it is cleared.

What It Means

Before Pulumi mutates a resource, it records a pending operation in the checkpoint. If the CLI is killed mid-operation — a lost network connection, a CI timeout, a SIGKILL, or a crashed provider — that pending marker is never cleared. On the next command Pulumi sees the marker and stops, because it genuinely does not know whether the underlying cloud resource was created, updated, or deleted before the interruption.

This is a safety mechanism, not corruption. The fix is to reconcile Pulumi’s view of the world with the cloud provider’s actual state, then remove the stale pending marker.

Common Causes

• A pulumi up or pulumi destroy was interrupted (Ctrl-C twice, terminal closed, CI job cancelled or timed out).
• The language or resource provider process crashed while an operation was in flight.
• Network loss between the CLI and the cloud API during a create/update/delete.
• The machine running Pulumi was rebooted or the container was evicted mid-deployment.
• A pulumi cancel was issued against an update that was actively changing a resource.

Diagnostic Commands

See exactly which resources are marked pending and in what operation:

pulumi stack --show-urns

Export the raw checkpoint so you can inspect (and back up) the pending_operations section before touching it:

pulumi stack export --file stack-backup.json

Reconcile Pulumi’s state with the real cloud resources without changing anything else:

pulumi refresh --stack prod --diff

Confirm in the cloud provider whether the pending resource actually exists (AWS example):

aws ec2 describe-instances --filters "Name=tag:Name,Values=web" --region us-east-1

Step-by-Step Resolution

1. Always back up the checkpoint first so you can restore if reconciliation goes wrong:

pulumi stack export --file stack-backup.json

2. In the common case, pulumi refresh is the correct and safe fix — it queries each resource in the provider and rewrites state to match reality, clearing the pending marker:

pulumi refresh --stack prod

3. If a create was pending but the resource was not actually created in the cloud, refresh removes it from state and your next up will recreate it — verify with a preview:

pulumi preview --stack prod

4. If refresh cannot clear it (for example the provider can no longer reach the resource), edit the exported checkpoint to remove the entry from "pending_operations", then re-import the corrected state:

pulumi stack import --file stack-backup.json

5. Run the update again and confirm the pending list is empty:

pulumi up --stack prod

Prevention

• Give interactive updates time to finish; avoid double Ctrl-C, which forces an unclean stop that leaves pending markers.
• Set generous CI job timeouts for pulumi up/destroy so pipelines are not cancelled mid-operation.
• Run Pulumi from stable, non-preemptible environments for production stacks; avoid spot/ephemeral runners that can be evicted.
• Enable state-store versioning (S3/GCS/Azure) so you can roll back to a pre-interruption checkpoint if needed.
• Make pulumi refresh a routine first step in recovery runbooks rather than manually editing state.

Related Errors

• the stack is currently locked — a live lock from another update, cleared with pulumi cancel, distinct from pending operations.
• error: could not deserialize deployment — actual checkpoint corruption, not a recoverable pending marker.
• resource ... has a problem — a provider-side failure during create, versus an interrupted operation.
• CommandError: code: 255 — an Automation-API wrapper that may itself report a pending-operations state.

Frequently Asked Questions

Is a pending operation the same as a corrupt state? No. It is a deliberate marker Pulumi writes before mutating a resource and could not clear because it was interrupted. A pulumi refresh usually reconciles it cleanly.

Will pulumi refresh delete my resources? Refresh does not modify cloud resources; it only reads them and updates Pulumi’s state to match. If a pending create never really happened, it removes that phantom entry so your next up recreates it.

When should I edit the checkpoint by hand? Only when refresh cannot resolve it — export the state, remove the entry from pending_operations, and re-import. Always keep the original export as a backup.

How do I avoid this in CI? Raise the job timeout so Pulumi is not cancelled mid-update, and run from stable (non-preemptible) runners. Recovery-runbook prompts are in the Pulumi prompt library.

Can I just run pulumi cancel? cancel clears a lock from an update believed to be in progress; it does not remove pending-operation markers. Use refresh for pending operations. More recovery walkthroughs are in the Pulumi guides.