Troubleshooting stuck deployments
Why a deploy can get stuck in the deploying state, and how to recover
A deployment normally moves from deploying to active within a minute or two. If it stays in deploying longer than expected, Astro AI flags it as “taking longer than usual” and surfaces recovery actions directly on the deployment: roll back to your last good version, cancel the deploy, redeploy, or restart. These actions remain available throughout.
Common reasons a deploy gets stuck
- Image pull errors — the container image cannot be pulled: a wrong tag, a private registry without credentials, or a build that has not finished pushing. Confirm the build completed and the image reference is correct.
- Insufficient resources or quota — the cluster cannot schedule the pod because CPU or memory requests exceed what is available, or the account is at its quota. Lower the requested resources or free up capacity.
- Failing readiness probes — the container starts but never reports healthy, so the deploy never completes. Confirm the agent listens on the expected port and its health endpoint returns success.
- Crash-looping containers — the container starts and exits repeatedly, usually from a bad start command, a missing secret or environment variable, or an unhandled startup error. The pod logs show the crash reason.
- Missing configuration — a required secret or environment variable is not set, so the agent cannot start.
How to recover
- Roll back to the last good version. A fresh redeploy usually hits the same wall, so the fastest fix is to return to the version that last deployed cleanly. Use “Roll back to last good version” on the stuck banner, or “Rollback to this revision” from an earlier entry in the deployment history.
- Cancel the deploy. Cancel an in-progress deploy to stop waiting on it instead of leaving it stuck until it times out. The stuck banner takes over so you can fix the configuration and redeploy, or roll back, right away. Any earlier running version is left in place, so a healthy deployment keeps serving.
- Check the pod logs and events. Open the pod on the deployment and read its logs and events to see what is blocking startup, then fix the underlying cause and redeploy.