- Newest
- Most votes
- Most comments
Unfortunately, there is no self-service API or CLI command to force a CloudFormation stack out of UPDATE_IN_PROGRESS when cancel-update-stack has been accepted but hasn't progressed. Based on the available CloudFormation operations, once you've issued cancel-update-stack and it's been recorded, the stack should transition to UPDATE_ROLLBACK_IN_PROGRESS and eventually UPDATE_ROLLBACK_COMPLETE. However, your situation appears to be an edge case where this normal progression hasn't occurred.
The cancel-update-stack operation is designed to work on stacks in UPDATE_IN_PROGRESS state and should cause the stack to roll back to its previous configuration. When the cancellation completes successfully, the stack should be set to UPDATE_ROLLBACK_COMPLETE. However, this assumes normal operation flow.
Regarding your specific questions:
-
No self-service force option exists: There is no documented API or CLI command that can force a stack out of UPDATE_IN_PROGRESS beyond cancel-update-stack, which you've already attempted.
-
Express Mode with disabled rollback: When using Express Mode with rollback disabled, CloudFormation normally disables automatic rollback by default. If a resource operation fails, the stack should enter a failed state rather than remaining indefinitely in UPDATE_IN_PROGRESS. Your situation—where the stack accepted the cancellation but hasn't transitioned—suggests an abnormal condition that may require AWS intervention.
-
DynamoDB resolution: Since all your resources, including the DynamoDB table, are reporting terminal COMPLETE states and the table itself is ACTIVE with all GSIs ACTIVE, resolving anything on the DynamoDB side is unlikely to help. The issue appears to be with CloudFormation's state management rather than the underlying resources.
Given that you've exhausted the standard recovery options and the stack has been stuck for over 22 hours with no resource-level operations in progress, your best path forward is to contact AWS through the AWS Support Center at https://console.aws.amazon.com/support/. You can open a case there even without a paid support plan (though response times will vary based on your support tier). This type of stuck stack situation typically requires AWS to intervene and manually transition the stack to a terminal state.
For future deployments, you might consider re-enabling rollback even with Express Mode by setting disableRollback to false in the deployment configuration, which would provide more predictable failure handling.
Sources
Cancel a stack update - AWS CloudFormation
Use CancelUpdateStack with a CLI - AWS SDK Code Examples
CancelUpdateStack - AWS CloudFormation
Choose how to handle failures when provisioning resources - AWS CloudFormation
Update: at ~ T+105h, my stack went from UPDATE_IN_PROGRESS to UPDATE_FAILED, but trying a new cdk deploy --express results in Error: unknown, and cdk deploy (without --express) refuses to run.
Waiting on AWS Support to manually intervene, this seems to hint at multiple bugs with the new --express flag.
answered a month ago
I'm in a similar boat. My stack progressed to
UPDATE_FAILED, but when I try to deploy, I see this message:This stack is in a UPDATE_FAILED state from a previous operation that used EXPRESS deployment mode with disable-rollback. Follow-up operations must use the same DeploymentConfig (mode=EXPRESS) until the stack reaches a *_COMPLETE state. To recover, submit the request with DeploymentConfig mode set to EXPRESS.I see it whether I deploy with the
--expressflag or not.The Cloudformation service team had to force my stack back into a good (non-express) state.
The service team has corrected the internal state on
grahamTkoInfraso it is no longer locked to Express mode and has re-enabled rollback on the stack. This clears the "must use the same DeploymentConfig (mode=EXPRESS)" block you were hitting, so the stack can accept a normal deployment again.Once they did that, I was able to roll back and deploy normally. Hopefully you have a similar outcome.
Thank you for reporting this issue. The underlying problem causing some stacks to become stuck in UPDATE_IN_PROGRESS after an Express mode (no-rollback) update failure has been identified and fixed globally as of July 6, 2026. All impacted stacks have also been remediated.
If you continue to experience this issue or encounter any other problems, please let us know.
answered a month ago
As of July 8th, my stack has changed status to
UPDATE_FAILED, but is refusing to be updated with or without the--expressflag. Perhaps me executingcancel-updateon the stack before caused it to be excluded from this global remedy? I've opened a support issue, hopefully they can get my stack unstuck.
Hello.
Would anything on the DynamoDB side (e.g. resolving a pending GSI operation) let CloudFormation finalize the stuck operation?
It is difficult to test this since I cannot reproduce your exact situation, but with standard CloudFormation, it is possible for the status to revert once the cause of the error is resolved.
While this concerns standard CloudFormation troubleshooting rather than Express Mode, it might be worth checking the information in the following documentation.
https://repost.aws/knowledge-center/cloudformation-stack-stuck-progress
I got into the same situation after trying to deploy a stack with the new --express flag. Good to know that this defaults to --no-rollback, I'll be changing my scripts to always opt for the rollback strategy.
My stack update failed because AWS Cognito refused an apparent change to my userpool, and the stack is still in UPDATE_IN_PROGRESS 27 hours later. I initiated cancel update 25 hours ago and this still hasn't made any progress.
I've opened a case with AWS Support even though I'm not on any support plans at the moment, I'll update this comment if they get back to me on that.
answered a month ago
Relevant content
asked 2 years ago
I am having the same issue; the stack is now stuck on UPDATE IN PROGRESS since 2026-07-02 15:00 UTC. Requesting the update cancellation does nothing. I was using express mode, and the issue was missing an export from another stack. I have since then added the missing export, but it didn't help. Maybe the reason for that is that I have requested an update cancellation before adding the missing export. Anyway, I am hoping for some resolution from the AWS.