Stack rollback

When CDK hands infrastructure changes to AWS CloudFormation, the result can be CREATE_FAILED or UPDATE_FAILED. CloudFormation then rolls the change back to the nearest stable configuration, so the application keeps serving from the last known-good deployment while the change fails. You will not see a half-applied broken environment — but the change you were trying to apply did not take effect.

The generated deploy job never runs a destructive or manual cdk destroy on your stack. Rollback is CloudFormation’s normal safety behavior, and it is safe to leave the stack in the rolled-back state while you diagnose.

Where to look

1. Open the failed deploy job in the GitHub Actions run.
2. Find the failing step: Deploy CDK stack wraps the CloudFormation work.
3. Capture a small excerpt around the failure line — the failing step name, the CloudFormation error, and the last few lines of output.

Read the CloudFormation events

The stack name is in the deploy job log (or in your project’s cdk-outputs.json / CDK app output). In the AWS Console (CloudFormation → your stack → Events), look at the last 5–10 events that show CREATE_FAILED, UPDATE_FAILED, or ROLLBACK:

• Timestamp
• Logical resource ID
• Resource type
• Status reason

The status reason on the failed resource is almost always the real cause. Common ones:

Reason pattern	What it usually means
AccessDeniedException / AuthFailure on an IAM/CloudFormation action	Deploy role is missing the permission this change needs
Stack: {…} was not found / resource not found	A resource the stack expects to reuse is missing or in a different region
Cannot satisfy the condition / InvalidTemplateParameter	A required CloudFormation parameter (environment variable, option) is absent
InvalidParameterValue / quota / TooManyRequests on a service	A request-level validation failure or a service quota reached
ValidationError on a network/region-specific resource	Resource placement or DNS/region mismatch

Map the CloudFormation status reason back to the step in the deploy job that emitted it. The deploy job step name (Ensure CDK bootstrap, Deploy CDK stack) plus the CloudFormation error tells you which part of the pipeline failed.

Don’t

Do not run a manual cdk deploy from your laptop as the first recovery step. The generated pipeline is the supported path; a manual deploy can drift your stack from what the pipeline expects. Manual cdk is an advanced recovery only (see CDK bootstrap).

Fix and retry

Fix the root cause the CloudFormation events point at — the most common is a missing permission on the deploy role or a missing parameter in your environment. Then re-run the deploy workflow from ScaleBop’s Pipeline page or from GitHub Actions. A retry re-applies the intended change against the already-rolled-back (stable) stack, so you do not lose the rollback.

If you repeatedly see a rollback for a specific change without changing the input, the issue is structural in that change — fix the code/config producing it before re-running.