Why this happens
A stabilisation timeout means the service was still in flux when time ran out, without a single failure decisive enough to classify. Common causes:- A capacity shortage. The cluster cannot place the new tasks, so the rollout waits for capacity that never arrives.
- Tasks cycling without tripping the circuit breaker. New tasks start, run briefly, and stop, but not in a pattern the breaker recognises as a hard failure.
- Slow drains. Old tasks take a long time to drain their connections, and the rollout cannot complete until they stop.
ecs_stabilise phase. The provider reason from ECS may include a stopCode when tasks were stopping during the window.
How to fix it
- Check the ECS service events for what kept the rollout from completing. The event stream names placement failures, stopping tasks, and drain progress in order.
- If the events show placement failures, the cluster is short of capacity. Free capacity or scale it up, then deploy again.
- If the events show tasks starting and stopping, read the stopped tasks’ logs. Treat it as a startup failure even though the breaker did not fire.
- If the events show old tasks draining slowly, check for long-lived connections holding the drain open. Shorter drain settings or closing idle connections lets the rollout finish.
- Deploy again once the blocker is cleared. If the service was healthy and only slow, a retry may complete without any change.
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.Related
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 timed-out rollout.