> ## Documentation Index > Fetch the complete documentation index at: https://docs.fjall.io/llms.txt > Use this file to discover all available pages before exploring further. # ecs.stabilise_timeout > The service did not stabilise in time The rollout started, but the ECS service did not reach a steady state before the deployment's stabilisation window ran out. 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. ## 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. The deployment failure sits in the `ecs_stabilise` phase. The provider reason from ECS may include a stopCode when tasks were stopping during the window. ## How to fix it 1. 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. 2. If the events show placement failures, the cluster is short of capacity. Free capacity or scale it up, then deploy again. 3. 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. 4. 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. 5. 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 How the circuit breaker and the ECS event tail protect your rollouts. The full deployment flow, phase by phase. Deploy from the CLI and read its failure output. Check what is currently running after a timed-out rollout.