# Docker Space stuck in APP_STARTING with stale runtime SHA > Source: > Published: 2026-06-20 09:58:09+00:00 Hmm. There are many similar known Space errors, but this one feels slightly different from all of them. If you have not already done so, I think it may be better to contact Hugging Face support at `website@huggingface.co` too. This does **not** look like a normal Docker Space startup problem anymore. From the evidence already posted, the suspicious part is not simply “the app does not start.” The unusual part is the combination of: `0.0.0.0:7860` `APP_STARTING` That combination makes this look less like a user-code issue and more like a stale Spaces runtime/control-plane state. In other words, I would not mainly focus on the usual fixes such as: `app_port` `EXPOSE` `startup_duration_timeout` Those checks are normally important, but they seem mostly ruled out by the current evidence. The thing I would ask HF to inspect is something like: Could this Space have a stale runtime record, stale image metadata, or stale health/status registration? The repository HEAD is newer than the runtime SHA, while the container appears to be serving HTTP 200 on the expected Docker Space port. | Compared with previous “Space stuck” reports | This case | |---|---| Same: Docker Spaces can get stuck even when the app-side code is not obviously broken. | The app appears reachable and Gunicorn is listening on `0.0.0.0:7860` . | Same: Some reports show stale runtime/build state after pushes, restarts, or factory rebuilds. | The runtime SHA remains older than the current repo HEAD. | Different: Many older cases are ordinary port/bind/startup-timeout problems. | The usual `app_port` , `EXPOSE` , bind-address, and basic health checks seem mostly ruled out here. | Different: Some stale-SHA cases are mainly `BUILDING` or queue-stall problems. | This looks more like `APP_STARTING` / health-status registration staying stale while the app is reachable. | Different: Some cases recover after waiting or another rebuild. | Here, restart/factory reboot apparently did not advance the runtime SHA. | So my short summary would be: Why I do not think this is the usual Docker Space startup issueSimilar to previous stuck-Space reports, but not an exact match. The unusual part is reachable app + correct port + stale runtime SHA + failed restart/factory-reboot recovery. That smells like a stale Spaces runtime/control-plane record rather than a normal Docker/app startup bug. I would treat this as: likely not a normal Docker Space startup failure, but a possible stale Spaces runtime/control-plane state. Since the key evidence is already in the thread, I would not spend too much time changing app code unless a new log clearly points to an app-side crash. I would escalate it and ask HF to inspect/reset the runtime record, image metadata, or health/status registration for the Space.