🚨 Pulumi Error: 'the current deployment has 1 resource(s) with pending operations' — Cause, Fix, and Troubleshooting Guide

Overview

error: the current deployment has 1 resource(s) with pending operations means a previous pulumi up was interrupted while a resource operation was in flight. Before Pulumi mutates a resource, it records a pending operation marker in state (creating, updating, or deleting). When the operation completes, the marker is cleared. If the process is killed — Ctrl-C at the wrong moment, a CI timeout, a crashed runner, a dropped network — the marker is left behind, and Pulumi refuses to run again until it knows the true state of that resource.

The full message tells you exactly what is stuck and how to clear it:

error: the current deployment has 1 resource(s) with pending operations:
  * urn:pulumi:dev::myproject::aws:ec2/instance:Instance::web, interrupted while creating

These resources are in an unknown state because the Pulumi CLI was interrupted while
operating on them. This is because a preview or update was interrupted, which left the
state in an inconsistent condition. To resolve, use the `pulumi cancel` command, or run
`pulumi refresh` to reconcile the state with the actual infrastructure.

This is a safety mechanism, not corruption. Pulumi is telling you it does not know whether that EC2 instance was actually created, and it will not guess.

Symptoms

• pulumi up, preview, or refresh immediately aborts with ... resource(s) with pending operations.
• The message lists a URN and a verb: interrupted while creating / updating / deleting.
• The previous run was Ctrl-C’d, hit a CI job timeout, or the runner died.
• No new work can proceed on the stack until the pending op is cleared.
• pulumi stack export shows a pending_operations array in the state JSON.

Common Root Causes

1. The update was interrupted mid-operation

The most common cause: someone pressed Ctrl-C, the terminal closed, or a laptop slept while pulumi up was applying.

* urn:...::Instance::web, interrupted while creating

2. CI job timeout or cancellation

A pipeline hit its wall-clock limit (or was manually cancelled) while a long-running resource — RDS instance, EKS cluster, CloudFront distribution — was still provisioning.

# CI kills the job after 10m; the RDS create needed 15m
##[error]The operation was canceled.

3. Runner crash or lost connectivity

The CI runner OOM-killed the process, or the network to the cloud/Pulumi backend dropped, so the completion was never recorded.

4. Backend/state write failure

Pulumi finished the cloud operation but could not write the cleared marker back to the state backend (S3 5xx, Pulumi Cloud blip), leaving the pending flag set.

5. A truly stuck cloud operation

The underlying resource is genuinely still creating/deleting on the cloud side (e.g. a distribution stuck in InProgress), and the CLI was interrupted while polling it.

How to Diagnose

First determine the real state of the resource named in the URN. For the EC2 example:

aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=web" \
  --region us-east-1 \
  --query 'Reservations[].Instances[].{Id:InstanceId,State:State.Name}'

Inspect the pending operations recorded in state:

pulumi stack export > stack.json
grep -A5 pending_operations stack.json

Decide based on reality:

• Resource does not exist in the cloud → the create never finished; drop the pending op.
• Resource exists in the cloud → the create succeeded but was not recorded; refresh will adopt it.

Confirm no other run is genuinely still in progress before you clear anything:

pulumi stack --show-urns

Fixes

Preferred — reconcile with reality via refresh. This queries the cloud for each resource and clears pending operations that no longer apply. It is non-destructive and correct in almost every case:

pulumi refresh
pulumi up

If refresh is blocked or you know the operation is dead — cancel. pulumi cancel clears the “another update in progress” lock; then export/import removes the stale pending marker. Note: pulumi cancel alone does not always remove pending ops, so pair it with refresh:

pulumi cancel
pulumi refresh

Manual state repair (last resort). When refresh cannot run, edit the exported state to drop the pending_operations entry, then re-import:

pulumi stack export > stack.json
# Remove the pending_operations array entry for the stuck URN, then:
pulumi stack import --file stack.json
pulumi up

If the resource was actually created but is untracked (exists in cloud, absent from state after you dropped the pending op), import it so Pulumi manages it instead of trying to recreate:

pulumi import aws:ec2/instance:Instance web i-0abc123def4567890

If it was never created, clearing the pending op and running pulumi up will create it cleanly.

What to Watch Out For

• Always check the actual cloud state before repairing — clearing a pending op without checking can strand a real, billable resource outside Pulumi’s tracking.
• Prefer pulumi refresh over hand-editing state; manual stack import is a last resort and easy to get wrong.
• This is distinct from conflict: another update is in progress — that is a state lock held by a concurrent/abandoned run; pending operations are interrupted resource ops. They can co-occur, so you may need pulumi cancel (lock) then pulumi refresh (pending ops).
• Give long-provisioning resources enough CI timeout headroom; interrupted RDS/EKS/CloudFront creates are the usual culprits.
• Do not run pulumi up twice in parallel against the same stack — it produces exactly these stuck states.
• Back up state (pulumi stack export) before any manual repair so you can roll back.

Related Guides

• Pulumi Error: ‘conflict: another update is in progress’ — Troubleshooting Guide
• Pulumi Error: ‘resource already exists’ — Troubleshooting Guide
• GitOps for Infrastructure Explained