# HF Space stuck at Starting **URL:** **Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C **Post date:** [November 27, 2025, 11:33pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-space-stuck-at-starting%2F170911%2F2 "2025-11-27T23:33:35Z") Judging solely from the visible symptoms, the Space process has started normally but communication between the process and the GUI is not working. Probably an address or port configuration error. * * * The short explanation in your specific case: - Your app **inside** the container is starting correctly (hence the logs and `127.0.0.1:7860`). - Hugging Face’s **health checker** sits **outside** the container and cannot see a healthy HTTP endpoint, so the Space never flips from **“Starting”** to **“Running”**. - The strongest hint is that it says: Below is a detailed breakdown: what “Starting” really means, how to interpret your logs, the main causes seen in the wild, and concrete code-level fixes/workarounds. * * * ## 1. What “Starting” means for a Space When Hugging Face runs a Space, there are two layers: 1. **Your process** inside a container 2. **The platform health checker** This means you can have: - Perfectly normal logs inside the container (like yours), - But the external checker still never sees a valid HTTP server, - So the UI shows “Starting…” for a long time and may eventually show a timeout error (`space was not healthy after 30 min`).([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Flaunch-timed-out-space-was-not-healthy-after-30-min%2F30176 "Launch timed out, space was not healthy after 30 min")) Your log snippet is exactly that pattern. * * * ## 2. Interpreting your log lines You wrote: ```plaintext ===== Application Startup at 2025-11-27 21:10:32 ===== 2025-11-27 21:10:52,072 | INFO | Scientry._init_logger | Logger initialized — writing logs to logs/scientry_2025-11-27_21-10-52.log 2025-11-27 21:10:52,073 | INFO | Scientry.config.env_config.validate | :white_check_mark: Environment configuration validated successfully. * Running on local URL: http://127.0.0.1:7860 * To create a public link, set `share=True` in `launch()`. ``` What each part means: - `Application Startup` + `Scientry._init_logger` + `env_config.validate` → Your code starts, config is validated, no obvious crash yet. - `Running on local URL: http://127.0.0.1:7860` → This is the standard Gradio-style message (or something Gradio-like under your `Scientry` wrapper): → It started an HTTP server **bound to loopback only** (`127.0.0.1`) on port `7860`. - On a local machine, `127.0.0.1:7860` is fine. On Spaces, however, the app should bind to **`0.0.0.0`** so the health checker and HF proxy can reach it. There is a very close forum report where a user’s Space was also stuck; their logs showed: > - Running on local URL: [http://127.0.0.1:7860](http://127.0.0.1:7860) Another user replied: > I think this is the cause. The contents of Gradio (server process) are waiting at a different address.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhugging-face-space-starting-taking-forever-time%2F150974 "Hugging Face Space starting taking forever time")) Exactly the same symptom: app listens on `127.0.0.1`, HF expects `0.0.0.0`. So: > Everything in your snippet says “the app is alive” but “only reachable inside itself”, which is why the external HF health check sees nothing and leaves the Space in “Starting”. * * * ## 3. The main causes that fit your case ### 3.1 Bound to `127.0.0.1` instead of `0.0.0.0` ← most likely for you Inside a container, these addresses are different: - `127.0.0.1` = “only allow connections from this process/container itself” - `0.0.0.0` = “listen on all interfaces”, including the one HF uses to probe your app On Spaces, HF expects your web server to listen on **`0.0.0.0`** , not just loopback. Forum answers explicitly point to the wrong listening address (`127.0.0.1`) as the reason a Space stays stuck.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhugging-face-space-starting-taking-forever-time%2F150974 "Hugging Face Space starting taking forever time")) If Gradio decides to bind to `127.0.0.1` (the “local URL” default), the app will work if you exec into the container and curl `127.0.0.1:7860`, but HF’s health checker, which connects from outside, will never see it. **Fix (conceptual):** Change your app so that it binds to `0.0.0.0` explicitly. **Typical fixes for common stacks:** - **Gradio / Blocks / Interface** - **FastAPI + uvicorn** - **Flask** Wherever you see `127.0.0.1`, `localhost`, or no host specified, adjust to `0.0.0.0`. * * * ### 3.2 Port mismatch: app not really on 7860 Hugging Face’s default expectation is: - Managed Spaces (Gradio/Streamlit etc.): app listens on port `7860`. - Docker Spaces: app listens on the port specified as `app_port` in the README YAML (default `7860`).([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-docker "Docker Spaces")) If your app runs on, say, port 8000 or 8501, but HF probes port 7860, it will: - See nothing on 7860, - Treat the Space as unhealthy and eventually time out. There are several concrete reports where the only fix was to add or correct `app_port` in README: - Node.js Space that kept timing out until they set: - A Streamlit/FastAPI Docker Space where the HF engineer explicitly said: **Fix:** - If this is a **non-Docker (managed) Space**, make sure your app uses `server_port=7860` or equivalent. - If this is a **Docker Space** : If your logs show `127.0.0.1:7860`, you are probably already on port 7860, but it is worth checking you haven’t changed it elsewhere. * * * ### 3.3 Root path `/` returns 404 or never responds For non-Gradio apps (FastAPI, Flask, Node, custom servers), HF’s health checker very likely calls `GET /` on the monitored port and expects: - A response with any 2xx/3xx status - Not a 404 or repeated error. In at least one “Launch timed out, space was not healthy” thread, users confirm that the fix was: - Run the app on port 7860, - And ensure `/` returns a valid response (not 404).([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Flaunch-timed-out-space-was-not-healthy-after-30-min%2F30176 "Launch timed out, space was not healthy after 30 min")) If your app only defines `/api/...` or similar and nothing at `/`, HF may consider the Space unhealthy even though the app is technically running. **Fix:** - For FastAPI: - For Flask: Gradio already serves a root page, so this mainly affects custom backends, not pure Gradio apps. * * * ### 3.4 Space starts but then dies (crash or permission error) Another family of “Starting forever” issues: the server starts, prints a normal log, but then: - Crashes due to a filesystem or permission problem, or - Exits because the main thread stops. Examples: - Docker + Streamlit Space with `PermissionError: [Errno 13] Permission denied: '/.streamlit'`. The app tried to write to `/` (root) which is not allowed in Spaces. The solution was to refactor Dockerfile to use a writable workdir (`/app`) and follow the official example.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fi-keep-getting-errno-13-permission-denied-streamlit%2F166664 "I keep getting [Errno 13] Permission denied: '/.streamlit'")) - Spaces where Dockerfile sets an unwritable working directory, or users mismatch container user / file ownership; logs show almost nothing, but the health check never sees a stable server.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fspace-stuck-on-starting-no-visible-logs-db-download-streamlit-app%2F166765%2F2 "Space stuck on “Starting” — no visible logs, DB download ...")) In your snippet, nothing yet indicates a crash, but it is worth: - Scrolling further down in the logs to see if any traceback appears. - Making sure you are not writing logs or data to forbidden paths like `/` instead of `/data`, `/app`, or `/tmp`. * * * ### 3.5 App takes too long to warm up If your app downloads huge models (tens of GB) or does expensive work before starting the HTTP server, Spaces can: - Stay in “Starting” for a long time, - End with: `Launch timed out, space was not healthy after 30 min`.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fspaces-launch-timed-out-space-was-not-healthy-after-30-min%2F42257 "Launch timed out, space was not healthy after 30 min")) This is particularly common with big LLMs or large DB downloads. The pattern in your log, with instant startup and a visible server line, does **not** look like this, so I would treat slow startup as a secondary suspicion, not the primary one. * * * ### 3.6 Platform/infrastructure issue on HF’s side There are also real cases where everything is configured correctly and yet Spaces get stuck in “Starting”: - Example: the popular `multimodalart/dreambooth-training` Space had duplicates where logs showed: - Other threads mention prolonged periods where many Spaces fail due to capacity or abuse (e.g. cryptominers draining CPU), again resolved by HF infra changes.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Flaunch-timed-out-space-was-not-healthy-after-30-min-space-keeps-on-building%2F63685 "Launch timed out, space was not healthy after 30 min ...")) When to suspect this: - A brand new minimal template Space (pure Gradio) also gets stuck on your account. - Your app is definitely binding to `0.0.0.0:7860` and `/` responds 200. - It used to work and suddenly doesn’t, without code changes. In that scenario, opening a topic on the HF forum with: - Space URL (even if private, you can at least share the name with HF staff), - Startup logs showing correct host/port, - Note that a minimal template also fails, is typically the right escalation path. * * * ## 4. Concrete checklist for your Space Here is an actionable sequence you can follow. ### Step 1 – Fix host and port in your app code 1. Find the place where you call `launch()` (for Gradio) or start your server. 2. Change it to something like: 3. Commit and push to the Space, then restart once. This directly addresses the `127.0.0.1` symptom that has been explicitly identified as the cause in a similar forum thread.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhugging-face-space-starting-taking-forever-time%2F150974 "Hugging Face Space starting taking forever time")) ### Step 2 – If Docker: align `app_port`, `EXPOSE`, and CMD If your Space uses `sdk: docker`: 1. Make sure the top of `README.md` looks like: 2. In `Dockerfile`: Examples (Streamlit, Node, etc.) and docs show that forgetting `app_port` is enough to cause “Starting”/timeout behavior, even when the app looks healthy in logs.([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-docker "Docker Spaces")) ### Step 3 – Ensure `/` returns something (for non-Gradio apps) If you are not using Gradio for the external page: - Add a small root route that returns HTTP 200 at `/`. - Verify locally: `curl http://127.0.0.1:7860/` returns something other than 404. Then push and restart. ### Step 4 – Check for silent crashes and permission issues After you fix host/port: - If the Space is still “Starting”, scroll further down in the logs: If you see a permission error, move that folder under `/app`, `/data`, or `/tmp`, and adjust your code. ### Step 5 – Cross-check with a minimal template Space Create a new, minimal Space (public or private) with: - The default Gradio “hello world” from HF’s UI. - No extra dependencies. If **that** new Space: - Quickly reaches “Running” → your account and infra are fine; the issue is in your code/config. - Gets stuck at “Starting” too → you likely hit a platform issue and should contact HF with both Space names and logs.([Hugging Face](https://huggingface.co/spaces/multimodalart/dreambooth-training/discussions/56 "Launch timed out, space was not healthy after 30 min")) * * * ## 5. Summary - Your logs show a server running on **`http://127.0.0.1:7860`**. That is fine locally but wrong for Spaces. HF’s health checker needs to reach **`0.0.0.0:7860`** , and if it cannot, the Space stays stuck on **“Starting”**. Similar issues have been reported and confirmed on the HF forums.([Hugging Face Forums](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhugging-face-space-starting-taking-forever-time%2F150974 "Hugging Face Space starting taking forever time")) - Main causes and fixes: --- _[View the full topic](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fhf-space-stuck-at-starting%2F170911)._