Skip to main content
The rollout started, but the ECS service never reached a steady state before the deploy ended. No CloudFormation resource failed, and no task from the new version was seen to stop. The cause could not be attributed automatically. It may sit in your AWS account, in the application, or in a slow but otherwise healthy rollout. The deployment failure sits in the ecs_stabilise phase, with indeterminate fault attribution.

​
What this code rules out

Fjall reaches ecs.stabilise_timeout only after the sharper ECS codes have been ruled out, in this order: Two consequences follow, and they are the fastest way to read the record:
  • No stopped task was recorded. The tasks the rollout launched were still running, or were never placed at all. Nothing crashed and looped.
  • The provider block carries no stopCode. A stopCode only ever accompanies a stopped task, so its presence would have produced ecs.task_start_failed. The provider message here is ECS’s rollout state reason, or a line such as rollout state IN_PROGRESS when monitoring ended.

​
Why this happens

Fjall gives one deploy 30 minutes of wall clock by default. A rollout that is slow but healthy, many tasks, a long target-group deregistration delay, or a long health-check grace period, can outlive that budget while ECS is still converging. Raise it with FJALL_DEPLOY_TIMEOUT_MS, set to whole milliseconds with no unit suffix.
The service has nowhere to put the new revision: no spare CPU or memory, no free IP addresses left in the subnets, or a service quota already at its ceiling. The service events say unable to place a task.
Long-lived connections hold the target group’s deregistration delay open, so the old tasks stay registered and the rollout cannot finish.
New tasks were still starting, or still inside their health-check grace period, when the deploy ended. Nothing failed, the clock simply beat the rollout.

​
How to fix it

  1. Read the ECS service events for the service named on the failure. The event stream lists placement failures, draining progress, and steady-state transitions in order.
  2. If the events show unable to place a task, the cluster is short of capacity. Free capacity, scale the cluster, or check the subnets for free IP addresses, then deploy again.
  3. If the events show old tasks draining, look for long-lived connections holding the drain open. Shorten the target group’s deregistration delay or close idle connections.
  4. If the deploy output says the CDK deploy exceeded its timeout, raise the budget and deploy again. Re-running on the same budget buys a second timeout, so Fjall never retries a timed-out deploy on its own.
  5. Check what is running before you retry. The previous version is usually still serving, because nothing switched over.
  6. Deploy again once the blocker is cleared. If the service was healthy and only slow, a retry can complete without any other change.
CloudFormation holds the AWS::ECS::Service resource in progress until ECS reports a steady state, and Fjall’s ECS tail only observes the rollout, it never stops one. Killing the CDK process at the deploy budget leaves the CloudFormation operation running in your account, so the rollout can still converge after the CLI reports this code. Fjall probes for that in-flight operation and re-attaches to it while any budget remains.

​
What Fjall shows you

The deployment’s detail page on fjall.io shows this code, the affected service, the verbatim ECS reason, and the deploy-time ECS event tail. The CLI prints the same information in its Error Detail block, and the deployments list shows the failure title on the deployment’s row.

​
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 rollout that never settled.