Why this happens
A container health check probes the application on a fixed schedule after start. The check fails when:- The application is not listening on its configured port. The process starts but binds a different port, or fails to bind at all.
- The health-check path is wrong. The check requests a route the application does not serve, so every probe returns an error.
- The start period is too short for a slow boot. The application is still initialising when the first probes run, and ECS counts those failures against it.
ecs_stabilise phase. The provider reason from ECS may include the stopCode for the failed tasks.
How to fix it
- Check the container health-check command and its start period. Confirm the command probes a route the application serves and that the start period covers your slowest boot.
- Confirm the application listens on its configured port. Compare the port the process binds at startup against the port the service and health check expect.
- Test the check locally. Run the image, wait for it to boot, then run the health-check command against it. It should succeed within the configured interval.
- If the boot is legitimately slow (cache warming, large framework startup), extend the start period so the first probes land after the application is ready.
- Deploy again once the check passes locally.
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 failed rollout.