Skip to main content
ECS tried to start tasks from your new version, watched them fail repeatedly, and triggered its deployment circuit breaker. On the default circuitBreaker: { rollback: true } the rollout was cancelled and the previously running version was left in place, so production kept serving traffic throughout. The failure came from the application’s code or configuration.

​
Why this happens

The circuit breaker fires when the new tasks keep stopping before the service can stabilise. Common causes:
  • The application crashes at boot. A bad configuration value or an unhandled startup error stops the container within seconds.
  • A secret or environment value the new version expects is missing, so initialisation fails.
  • The schema-version boot gate refuses to start because the database schema does not match what the new code expects.
  • The image itself is broken. The entrypoint fails or a dependency is missing from the build.
The deployment failure sits in the ecs_stabilise phase. The provider reason from ECS may include the stopCode for the failed tasks.

​
How to fix it

  1. Check the application logs for the stopped tasks. The new version could not start, and the boot output names the reason in almost every case.
  2. Reproduce the boot locally. Run the same image with the same environment and watch it start. A crash that happens in ECS usually happens on your machine too.
  3. If the logs mention a missing secret or environment value, add it and redeploy. Compare the new version’s expected configuration against what the service actually receives.
  4. If the schema gate refused to boot, run the pending migration first, then deploy the code that depends on it.
  5. Deploy again once the boot failure is fixed.
The rollback is automatic and the previous revision was left in place, so the service was never fully switched over. When no new task ever passes its health check, no traffic reaches the new version at all, but a partially-healthy rollout does serve some traffic from the new tasks before the breaker trips. See Deployment safety for that case.
A service that sets circuitBreaker: { rollback: false } gets detection without reversion. The breaker still trips and ECS marks the deployment failed, which is what produces this code, but the failed revision stays live. Roll back yourself with fjall rollback <app>, then fix the boot failure. See the circuit-breaker options.

​
What Fjall shows you

The deployment’s detail page on fjall.io shows the failure title, this code, the per-deployment detail, the ECS reason verbatim under “ECS said”, the remediation steps, and a link back to this page. The Steps timeline ends with the latest ECS event message once every step has completed. The deployments list carries the failure title on the deployment’s row. Non-interactive CLI runs print the same fields in an Error Detail block.

​
Next Steps

Deployment safety

How the circuit breaker and the ECS event tail protect your rollouts.

Deploy an application

The full deployment flow, phase by phase.

fjall deploy

Deploy from the CLI and read its failure output.

fjall releases

Check what is currently running after a rollback.