ERROR REFERENCE
Resource did not stabilize
The service accepted CloudFormation's create or update call, but the resource never reached its steady state within the wait window, so CloudFormation gave up. The stabilization wording is only the wrapper — the real cause is usually quoted inside it.
WHAT IT MEANS
What this error means
The phrasings — Resource ... did not stabilize,
HandlerErrorCode: NotStabilized, Exceeded attempts
to wait — all mean CloudFormation polled the resource's status
until its patience ran out. Three distinct causes hide behind that:
- A nested failure from the service handler. When the log contains a
Resource handler returned messageline, the quoted message inside it is the actual error — the stabilization failure is just how it surfaced. - A resource that is genuinely slow to provision. ACM certificates waiting on DNS validation, CloudFront distributions, RDS instances — these can legitimately outlast the wait window when an external dependency has not cleared.
- A handler that never signals completion. Custom resources and third-party handlers that crash or never send their response leave CloudFormation waiting until the timeout.
FIX
How to fix it
-
Find the nested message first. Look for
Resource handler returned messagein the log (or the resource's own event in the service console) and treat that quoted reason as the failure to fix. Only fall back to the steps below when there is none. - For slow-by-design resources: confirm the external dependency — ACM validation records actually published, CloudFront quota headroom, RDS instance-class availability — then retry. The same template often succeeds once the dependency clears.
- For custom resources and third-party handlers: check the handler function's own logs for the invocation. A handler that crashed or never sent its CloudFormation response is indistinguishable from a slow resource until you look at its logs.
AUTOMATE THE TRIAGE
Diagnose this automatically
SAM Doctor recognizes the stabilization wording (high confidence) and surfaces the nested handler message and resource type ahead of the generic guidance — if the underlying cause is a permission denial, both findings are reported with the denial first. Runs locally; no AWS access, no log upload.
python -m pip install sam-doctor
sam-doctor diagnose deployment.log --format markdownRELATED
Related errors
- DELETE_FAILED — the deletion-side sibling: a resource that will not go away instead of one that will not settle.
- Stack is in ROLLBACK_COMPLETE state and can not be updated — where a first-deploy stabilization failure often strands the stack.
- Denied because no policy allows it — a frequent nested cause inside stabilization wrappers.