Fix: Stack is in ROLLBACK_COMPLETE state and can not be updated

Your CloudFormation deploy failed and now every attempt to update the stack is rejected with a message that the stack is in ROLLBACK_COMPLETE and cannot be updated. This is one of the most confusing CloudFormation states because it looks like a stack you should be able to fix in place, but it is actually terminal. It only happens when the very first create of the stack failed. The path forward is not another update: it is to fix what broke, delete the stack, and create it again.

Stack:arn:aws:cloudformation:us-east-1:123456789012:stack/my-stack/abc123 is in ROLLBACK_COMPLETE state and can not be updated.

What this error means

When you create a brand new stack and any resource fails to provision, CloudFormation rolls back the whole create, deletes the resources it managed to make, and puts the stack in ROLLBACK_COMPLETE. That state means the create was fully undone. Because the stack never reached a successful, stable configuration, there is no prior good state to update toward, so CloudFormation refuses any update-stack call and returns this error. The only valid transition out of ROLLBACK_COMPLETE is deletion. This is different from UPDATE_ROLLBACK_COMPLETE, which is what you get when a later update fails and rolls back to the previously working configuration: that state is healthy and fully updatable. Seeing ROLLBACK_COMPLETE specifically tells you the first create never succeeded.

Common causes

• A resource in the template could not be created (an invalid property, an unavailable instance type, a name collision, or an IAM permission gap).
• A parameter value was wrong, so a resource was configured in a way AWS rejected.
• A dependency or reference in the template pointed at something that did not exist or was not ready.
• A service quota was exceeded during the create, so a resource could not be provisioned.
• A custom resource or Lambda-backed resource failed or timed out during the initial create.

How to fix it

STABILIZE

1. Confirm the state so you are certain this is a first-create rollback and not a failed update:

aws cloudformation describe-stacks \
  --stack-name my-stack \
  --query 'Stacks[0].StackStatus' \
  --output text

If this returns ROLLBACK_COMPLETE, the stack is terminal and must be recreated. If it returns UPDATE_ROLLBACK_COMPLETE, stop here: that stack is updatable and this article does not apply.

DIAGNOSE

1. Find the resource that failed the original create so you do not repeat the mistake. Read the stack events and filter to the failures:

aws cloudformation describe-stack-events \
  --stack-name my-stack \
  --query 'StackEvents[?ResourceStatus==`CREATE_FAILED`].[LogicalResourceId,ResourceStatusReason]' \
  --output table

2. Read the ResourceStatusReason for the first failure in the timeline. That first failure is the root cause; the later ones are usually just the rollback cleaning up. Correct the template or parameters based on that reason.
3. Before deleting, confirm nothing valuable survives. Check for any resource with a DeletionPolicy of Retain and for imported resources:

aws cloudformation list-stack-resources \
  --stack-name my-stack \
  --query 'StackResourceSummaries[].[LogicalResourceId,ResourceType,ResourceStatus]' \
  --output table

FIX

1. Delete the failed stack. This clears the name and removes any resources left from the rollback:

aws cloudformation delete-stack --stack-name my-stack
aws cloudformation wait stack-delete-complete --stack-name my-stack

2. Recreate the stack from the corrected template and parameters:

aws cloudformation create-stack \
  --stack-name my-stack \
  --template-body file://template.yaml \
  --parameters file://parameters.json \
  --capabilities CAPABILITY_NAMED_IAM

3. Watch the create to completion so you catch any remaining issue while the events are fresh:

aws cloudformation wait stack-create-complete --stack-name my-stack

How to prevent it

• Validate and lint templates before deploying so structural mistakes never reach a create.
• Deploy new stacks with change sets first so you review the plan before executing.
• Use --disable-rollback (or set the rollback configuration) on first creates in development, so failed resources stay for inspection instead of forcing a delete-and-recreate cycle.
• Check service quotas for the resources a new stack needs before the first create.
• Keep first-create deploys in a staging account so a terminal rollback never blocks production.

When to call a senior engineer

Call for help when a stack keeps landing in ROLLBACK_COMPLETE on every recreate and the root cause is not obvious from the events, when the failed stack holds retained or imported resources you cannot safely delete, or when the same template must be recovered across many accounts or regions at once. Erzon engineers can find the true first failure, recover the stack without losing anything that matters, and leave you with a deploy that succeeds the first time.