# Docker Space stuck in APP\_STARTING with stale runtime SHA **URL:** \ **Category:** Spaces\ **Created:** [June 20, 2026, 6:25am UTC](https://discuss.huggingface.co/t/docker-space-stuck-in-app-starting-with-stale-runtime-sha/176992 "2026-06-20T06:25:56Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![K1ngston](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/k1ngston/32/60977_2.png) [@K1ngston](https://discuss.huggingface.co/u/K1ngston)\ **Post date:** [June 20, 2026, 6:25am UTC](https://discuss.huggingface.co/t/docker-space-stuck-in-app-starting-with-stale-runtime-sha/176992/1 "2026-06-20T06:25:56Z")
My public Docker Space is stuck in APP\_STARTING: Space: > **[The Simplest Video Editor - a Hugging Face Space by K1ngston](https://huggingface.co/spaces/K1ngston/video-editor)** > > This web app lets you open any video file, then cut out sections, change its speed, resize, or crop the picture exactly how you want. After setting your preferences, you can render and download the... Repository SHA: 9f937e5c2d0b800b738807f3c5e5ad17f2460571 Reported runtime SHA: b9eef774b06240e8c93f2c62fe7ef06403194fd5 The application itself works and returns HTTP 200. Gunicorn starts normally and listens on 0.0.0.0:7860, but the Space status and runtime SHA never update. I have already tried: - Restart Space - Factory reboot - Pause followed by restart - Restarting through both the web UI and HF CLI The runtime logs contain no startup error. Could the Space runtime state be reset manually? ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2026, 9:58am UTC](https://discuss.huggingface.co/t/docker-space-stuck-in-app-starting-with-stale-runtime-sha/176992/2 "2026-06-20T09:58:09Z")
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. * * * ## My current read 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: - the app appears to answer HTTP 200 - Gunicorn is listening on `0.0.0.0:7860` - the Space still reports `APP_STARTING` - the runtime SHA is older than the repository HEAD - restart / factory reboot attempts apparently do not move the runtime SHA forward 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: - adding `app_port` - changing the bind address - changing `EXPOSE` - increasing `startup_duration_timeout` - making another random dummy commit - changing dependencies without a new error pointing there 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. ## Same vs different | 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: > Similar 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. > **Why I do not think this is the usual Docker Space startup issue** > > For Docker Spaces, the usual first things to check are documented around the Space README metadata and Docker port wiring: > > - Docker Spaces use `sdk: docker` in the README YAML. > - The exposed app port can be set with `app_port`. > - The default exposed port is `7860`. > - The app should listen on the configured port. > - If multiple internal ports are needed, HF suggests using a single exposed port plus a reverse proxy. > > Reference: > > - [Hugging Face docs: Docker Spaces](https://huggingface.co/docs/hub/spaces-sdks-docker) > > The usual failure pattern is: > > | Normal Docker Space failure | Why it seems weaker here | > | --- | --- | > | App only binds to `127.0.0.1` | Here, Gunicorn is reportedly listening on `0.0.0.0:7860`. | > | Wrong `app_port` | The app appears reachable on the expected port. | > | Dockerfile exposes a different port | The posted evidence suggests the running service is already on `7860`. | > | App never becomes healthy before timeout | The app reportedly returns HTTP 200. | > | Python process crashes before serving | Gunicorn appears to be alive and serving. | > > This does not prove the app has no bugs. It just means the main symptom does not look like the standard “container never served anything on the expected port” case. > **Why \`startup\_duration\_timeout\` is probably not the main lever** > > `startup_duration_timeout` is useful when the Space genuinely needs more time before becoming healthy. HF documents it as the maximum time a Space is allowed to start before timing out and being marked unhealthy. > > Reference: > > - [Hugging Face docs: Spaces Configuration Reference](https://huggingface.co/docs/hub/spaces-config-reference) > > That setting is useful for cases like: > > - slow model downloads during startup > - long compilation > - very slow first import > - first-run setup that exceeds the default startup window > > But here the important detail is different: the app already appears to be reachable, while the runtime SHA remains stale. > > So increasing `startup_duration_timeout` might hide a startup-latency problem, but it would not really explain why the Space runtime metadata still points to an older commit. > **Similar public reports I found** > > I found several related reports, but none seems like a perfect one-to-one match. > > | Related report | Similarity | Difference | > | --- | --- | --- | > | [Space stuck on “Starting” badge despite app running fine on port 7860](https://discuss.huggingface.co/t/space-stuck-on-starting-badge-despite-app-running-fine-on-port-7860/174315) | Very close: app reachable, port looks correct, status remains stuck, runtime SHA appears stale. | In that case, the report was framed more around the badge/status not flipping to Running. | > | [Space stuck, factory rebuild returns 500](https://discuss.huggingface.co/t/space-stuck-factory-rebuild-returns-500/176506) | Close: rebuild/restart path fails and the Space appears stuck on old runtime/build state. | More focused on factory rebuild returning 500 and build trigger failure. | > | [Space stuck in broken runtime-control state: build succeeds, Factory reboot returns 503, restart API fails](https://discuss.huggingface.co/t/space-stuck-in-broken-runtime-control-state-build-succeeds-but-factory-reboot-returns-503-and-restart-api-fails/174361) | Close: points toward a Spaces-side control-plane/runtime-control problem rather than app code. | More about explicit 503/restart API failure. | > | [Space stuck in BUILDING for 12+ hours — zombie build worker](https://discuss.huggingface.co/t/space-stuck-in-building-for-12-hours-zombie-build-worker/174761) | Related: old runtime/build state can persist in strange ways. | Mostly a `BUILDING` / worker-stall case, not exactly `APP_STARTING` with reachable app. | > | [Stuck in starting [Docker Spaces]](https://discuss.huggingface.co/t/stuck-in-starting-docker-spaces/131043) | Related: Docker Space stuck in Starting. | More like a conventional Docker Space health/startup configuration issue. | > > The closest family of problems is therefore: > > > stale runtime / stale SHA / stuck health-status registration / stuck Spaces control-plane state > > rather than: > > > ordinary Dockerfile problem / wrong port / slow startup / dependency crash > **Why contacting HF support seems reasonable** > > The important point is that a user can usually fix these: > > - app code crash > - missing dependency > - wrong port > - wrong bind address > - missing `app_port` > - slow startup > - disk/cache issue > - bad Dockerfile command > > But a user usually cannot directly fix these: > > - stale runtime record > - stale image metadata > - stuck health/status registration > - stuck Space control-plane state > - broken restart/factory-rebuild backend state > > The second group is exactly why this feels worth escalating. > > The forum thread already contains most of the useful evidence, so I would keep the support message short and point to the thread. > > Possible wording: > > ```plaintext > Hi HF team, > > Could you please check whether this Space has a stale runtime record, stale image metadata, or stale health/status registration? > > The repository HEAD is newer than the runtime SHA, but the container appears to be serving HTTP 200 on the expected Docker Space port. Restart/factory reboot attempts do not seem to move the runtime SHA forward. > > Forum thread: > > > Space: > > > ``` > > For contact route, `website@huggingface.co` is also mentioned in HF community/support contexts, and several stuck-Space forum reports are effectively the kind of case where HF-side inspection may be needed: > > - [How can I contact with the Hugging Face Team?](https://discuss.huggingface.co/t/how-can-i-contact-with-the-hugging-face-team/75427) > - [Hugging Face docs: Two-Factor Authentication recovery](https://huggingface.co/docs/hub/security-2fa) ## Bottom line 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. ---
**Author:** ![masonreed11](https://avatars.discourse-cdn.com/v4/letter/m/ccd318/32.png) [@masonreed11](https://discuss.huggingface.co/u/masonreed11)\ **Post date:** [June 21, 2026, 4:07am UTC](https://discuss.huggingface.co/t/docker-space-stuck-in-app-starting-with-stale-runtime-sha/176992/3 "2026-06-21T04:07:54Z")
If the app is healthy (HTTP 200 + Gunicorn running), this looks like a stale HF runtime state rather than an app issue. Try forcing a new build with a small commit, then do a factory rebuild. If the runtime SHA still won’t update, it’s likely a Hugging Face-side sync problem and support may need to reset the Space runtime. ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 21, 2026, 8:04am UTC](https://discuss.huggingface.co/t/docker-space-stuck-in-app-starting-with-stale-runtime-sha/176992/4 "2026-06-21T08:04:45Z")
I think HF is investigating. Maybe this case too? [Space stuck at "Starting" - health checker not responding - June 20 2026 - #6 by hysts](https://discuss.huggingface.co/t/space-stuck-at-starting-health-checker-not-responding-june-20-2026/177005/6)