Skip to content
ScaleBop← Back to app

Deploy failed

ScaleBop reports this as deploy with error code cdk_deploy_failed. That one code covers every failure in the deploy job. The job log says which one it actually is. Open View GitHub run, then the failed deploy job, and match the error text.

What the deploy log says Page
Could not assume the role, or the web identity token could not be validated OIDC token validation
Bootstrap stack missing, or Ensure CDK bootstrap failed CDK bootstrap
Build container image, Log in to Amazon ECR, or Push image to ECR failed Container image below
ECS service did not stabilize, or the deployment circuit breaker rolled back Container image below
CloudFormation failed, rolled back, or Deploy CDK stack failed after bootstrap Stack rollback

The step name is the fastest split: Configure AWS credentials is OIDC, Ensure CDK bootstrap is bootstrap, the image steps are your container, and Deploy CDK stack is the application stack.

Container image and rollout

Section titled “Container image and rollout”

For container apps, the deploy job builds your Docker image, pushes it to the stack’s Amazon ECR repository, then deploys the stack with that image. CloudFormation waits until the new tasks pass the load balancer health check, and rolls back to the previous image automatically if they never do, so your live app keeps running on the last good release.

  • Image build failed. The Build container image step shows the Docker error. It is usually a Dockerfile or dependency problem in your repository; reproduce it with docker build locally.
  • ECR push failed (denied, unauthorized). The deploy role cannot push to the repository. Check that the workflow assumes the deploy role for this account and region.
  • Rollout rolled back. The new container started but never became healthy. The Diagnose ECS rollout failure step prints the service events and the reason the last tasks stopped (for example a crash on start, a missing environment variable, or the app not answering on its health path). Fix the cause and re-run the workflow.

On the very first deploy, the job creates the stack once with a small placeholder server so the ECR repository exists to push to. That step is skipped on every later deploy.

A timeout or a cancelled run during deploy is none of these. Re-run the workflow from the project’s deployment history, or from GitHub Actions, when you are ready. If the same step fails again, use the table above.