Repository navigation
Request for More Info In Sam Deploy ChangeSet Failures #9154
Description
Describe your idea/feature/enhancement
I made changes to my template.yaml that caused my sam deploy to fail with this message: “Error: Failed to create changeset for the stack: fbp, ex: Waiter ChangeSetCreateComplete failed: Waiter encountered a terminal failure state: For expression "Status" we matched expected path: "FAILED" Status: FAILED. Reason: The following hook(s)/validation failed: [AWS::EarlyValidation::ResourceExistenceCheck]. To troubleshoot Early Validation errors, use the DescribeEvents API for detailed failure information.“
If I run this CLI:
aws cloudformation describe-events --stack-name --region us-east-1 --change-set-name "arn:aws:cloudformation:us-east-1:768286545465:changeSet/samcli-deploy1785624984/45c53ade-62a4-415f-ac7c-fc27e63b06d8”
I get output that shows me what the actual issue is.
Proposal
Can the error ouput for sam deploy failures be augmented with more detailed error information? It would save developers a lot of time to be able to see this right away
Activity
jakegold1647 commentedon Aug 11, 2026
Ran into this same thing. Worth noting the error you pasted literally ends with "use the DescribeEvents API for detailed failure information". The CLI already knows where the useful text is, it just makes you go get it yourself.
The general shape of it:
sam deploysurfaces the stack-level status (CREATE_FAILED,UPDATE_ROLLBACK_COMPLETE) or the changeset waiter message, while the text you actually need lives inResourceStatusReasonon the individual stack events.Two details that matter if this gets picked up:
The first failed resource in event order is the one worth showing. Everything after it is rollback noise, and there is usually a lot of it, so "most recent event" is the wrong thing to surface.
For resources backed by a CloudFormation registry handler,
ResourceStatusReasonoften nests a second message inside it (Resource handler returned message: "..."). That inner string is the actual cause, and it currently comes through escaped, which buries it.Disclosure, I maintain a small MIT-licensed CLI that does this locally today. It reads a deploy log you already have and reports the first matching failure with the evidence lines and a link to the relevant AWS doc. It does not call AWS, and it says "no match" rather than guessing when nothing fits. Not proposing it as a substitute, the fix belongs in the CLI. Mentioning it in case the pattern matching is useful reference: https://github.com/jakegold1647/sam-doctor
ccSchwing commentedon Aug 11, 2026
Jake —
Thanks for the response. This looks exactly like what i need. I’ll give it a go
Thanks and regards,
—ccs