# Cannot restart my private space: "503. Something went wrong when restarting this Space." **URL:** \ **Category:** Spaces\ **Created:** [June 29, 2026, 11:27am UTC](https://discuss.huggingface.co/t/cannot-restart-my-private-space-503-something-went-wrong-when-restarting-this-space/177235 "2026-06-29T11:27:58Z")\ **Posts on this page:** 1\ **Showing post:** 2
**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 29, 2026, 2:52pm UTC](https://discuss.huggingface.co/t/cannot-restart-my-private-space-503-something-went-wrong-when-restarting-this-space/177235/2 "2026-06-29T14:52:17Z")
Hmm… with only a 503 error, it is hard to narrow this down. If you can see a concrete error in the build or container logs, there may be cases where this can be fixed from the user/repo side. But **if no useful logs appear, issues like this often need Hugging Face support to check the Space from their side, e.g. via [website@huggingface.co](mailto:website@huggingface.co)**: * * * I would first separate this into two different situations: 1. **The Space is actually reaching the build/container phase, and the UI logs show a concrete error.** In that case, this may still be fixable from your side: dependency error, missing secret, wrong port, startup timeout, app crash, etc. 2. **Restart / Factory rebuild fails, but no new Build or Container logs appear at all.** In that case, I would stop treating it as only an application-code problem. It may be stuck before your app code is even reached: Space lifecycle state, scheduling/build dispatch, stale runtime state, or a policy/lock state that only HF staff can inspect. Since your Space is private, other forum users cannot see the source, app, logs, or settings. So the most useful next step is not more guessing, but checking **what the Space UI shows** and whether the logs actually move. > **1. First GUI checks I would do** > > From the Space page, I would check these first, without using CLI/API yet: > > | Where in the UI | What to check | Why it matters | > | --- | --- | --- | > | Space status / badge | `Paused`, `Building`, `Preparing`, `Starting`, `Running`, `Runtime error`, etc. | Tells whether the Space is failing before build, during build, during startup, or after startup. | > | **Open Logs** | Whether **Build logs** or **Container logs** update after Restart / Factory rebuild | This is the most important split. | > | Settings | Whether Restart / Factory rebuild fails immediately or after some time | Immediate failure can mean the operation is not reaching the normal build/container phase. | > | Files / README.md | `sdk`, `app_file`, `python_version`, `sdk_version`, and Docker `app_port` if applicable | Config mistakes can cause normal build/startup failures. | > | Warning banners | Words like `flagged`, `abusive`, `disabled`, `suspicious`, `quota`, `capacity`, etc. | If the UI explicitly shows a lock/policy/quota condition, code edits may not be enough. | > | Hardware indicator / Settings page | Whether hardware/settings controls load normally or spin/fail | If settings/runtime metadata is stuck, it may be above the app layer. | > > Hugging Face’s Docker Space guide shows the normal UI debugging path: use **Open Logs** , then check the **Build** tab and **Container** tab. In a normal Docker Space, Build logs should show build/image/scheduling steps, and Container logs should show the running server status such as `Uvicorn running on http://0.0.0.0:7860`. > > References: > > - [HF Docker Space first demo: Debugging with Build and Container logs](https://huggingface.co/docs/hub/spaces-sdks-docker-first-demo#debugging) > - [HF Spaces overview: Spaces are git repos and rebuild on commits](https://huggingface.co/docs/hub/en/spaces-overview) > - [HF Spaces visibility: private Spaces are visible only to owner/collaborators](https://huggingface.co/docs/hub/en/spaces-overview#space-visibility) > **2. Main split: do the Build or Container logs move?** > > The key question is: > > > After you click Restart or Factory rebuild, do the Build logs or Container logs get a new timestamp / new lines? > > That single observation changes the interpretation a lot. > > | Observation | What I would suspect first | > | --- | --- | > | Build logs update and show a dependency/build error | Repo/build configuration issue | > | Build succeeds, Container logs show traceback/crash | Runtime/app issue | > | Container logs show app started but Space is still unhealthy | Port/bind/startup/health/routing issue | > | Build logs do not update at all | Build dispatch / scheduler / Space state issue | > | Container logs do not update at all | Container may never be started | > | Restart and Factory rebuild both immediately return 503 | The failure may be happening before normal build/container startup | > | A new commit does not start a new build | More evidence that this may be above the app-code layer | > > If logs move, there is usually something actionable from the repo side. > > If logs do **not** move, repeatedly editing random files may not help much, because the new code may not be getting built or run at all. > > Related examples with similar symptoms, not necessarily the same root cause: > > - [Restart error 503 / Factory reset / No rebuild](https://discuss.huggingface.co/t/restart-error-503-factory-reset-no-rebuild-same-with-other-space/173779) > - [Docker Space gets paused and restart returns 503 with only “Build queued” in logs](https://discuss.huggingface.co/t/spaces-docker-build-pauses-and-503-error-on-restart/171149) > - [Factory rebuild from Space settings as the usual clean rebuild route](https://discuss.huggingface.co/t/can-i-force-rebuild-a-huggingface-space/18419) > > These links are only comparable reports / references. They do **not** prove that your Space has the same cause. > **3. Cases that may still be fixable from your side** > > If the UI logs show a concrete error, I would first treat it as a normal repo-side or runtime-side issue. > > Common repo-side cases: > > | Log area | Possible user-side fix | > | --- | --- | > | Build logs | Fix `requirements.txt`, `pyproject.toml`, `apt.txt`, Dockerfile, package versions, Python version, missing files, wrong casing | > | Container logs | Fix Python/Node traceback, missing imports, missing environment variables, missing secrets, auth errors | > | Startup/health | Make sure the app listens on the expected host/port and becomes ready in time | > | Model/data loading | Avoid downloading huge files at every startup; move large downloads to build time if possible | > | Permissions/cache | Fix write paths and cache directories, especially in Docker Spaces | > > For Docker Spaces, I would specifically check: > > - Does `README.md` have `sdk: docker`? > - If using a custom port, does `README.md` have the correct `app_port`? > - Does the app actually listen on that same port? > - Does it bind to `0.0.0.0`, not only `127.0.0.1`? > - Does the root endpoint return quickly enough? > - Are required secrets/variables configured in Space Settings? > > HF’s Docker docs say that the default Docker Space port is `7860`, and `app_port` can be set in the README YAML block. The first Docker Space tutorial also uses `uvicorn ... --host 0.0.0.0 --port 7860`, which is a useful pattern to compare against. > > Useful official references: > > - [Docker Spaces](https://huggingface.co/docs/hub/spaces-sdks-docker) > - [First Docker Space tutorial: `app_port`, `0.0.0.0`, and logs](https://huggingface.co/docs/hub/spaces-sdks-docker-first-demo) > - [Spaces configuration reference](https://huggingface.co/docs/hub/spaces-config-reference) > > Also check startup time. The config reference documents `startup_duration_timeout`, which is the maximum time the Space is allowed to start before being considered unhealthy. It also documents `preload_from_hub`, which can help when large models/files would otherwise be downloaded at runtime. > > Relevant docs: > > - [Spaces config: `startup_duration_timeout`](https://huggingface.co/docs/hub/spaces-config-reference#startup_duration_timeout) > - [Spaces config: `preload_from_hub`](https://huggingface.co/docs/hub/spaces-config-reference#preload_from_hub) > **4. Cases where editing code may not be enough** > > If all of these are true: > > - Restart returns 503. > - Factory rebuild also returns 503. > - Build logs do not get new lines. > - Container logs do not get new lines. > - A new commit does not trigger a new build. > - The Space stays `Paused`, `Building`, `Preparing`, or `Starting`. > - The UI only gives a `Root=...` request ID. > > Then I would not assume the app code is the main thing to debug. > > That pattern suggests the failure may be happening before the application is actually built or started. Possible categories are: > > | Category | What it would look like | > | --- | --- | > | Build dispatch / scheduler state | No new build starts, logs stay stale/empty | > | Runtime-control / lifecycle state | Restart/factory rebuild cannot transition the Space out of a stuck state | > | Stale runtime metadata | UI/status/runtime state does not match the latest repo state | > | Policy/lock/quota/capacity condition | UI or internal runtime state blocks restart/build | > | Wider infrastructure incident | Multiple users report similar failures around the same time | > > This is where HF staff/support may need to look at server-side state. The community can help interpret public logs and config, but it cannot inspect HF’s backend scheduler/runtime state for a private Space. > > The `Root=...` value is still useful. I would save it together with the exact UTC time and action that produced it, because it may help HF trace the failed backend request. But forum users generally cannot decode that ID by itself. > > Also, checking the [HF status page](https://status.huggingface.co/) can be useful. A green status page does not rule out a Space-specific stuck state, but if there is an active Spaces/Spaces Proxy incident, that changes the interpretation. > **5. One branch to check only if the UI explicitly says so: flagged / policy / lock state** > > I would **not** assume this from the 503 alone. > > However, if the Space UI, logs, or runtime information explicitly says something like: > > - `flagged` > - `abusive` > - `disabled` > - `suspicious` > - `policy` > - `RepoScanner` > - `Cloudflare` > - `tunnel` > - `proxy` > > then code edits alone may not fully unblock the Space. > > There are forum reports where Spaces became paused/blocked and restart/factory rebuild did not recover them until HF-side review. Again, this is only a branch to check if the UI/runtime explicitly shows such wording. > > References: > > - [Example: flagged as abusive / cannot restart](https://discuss.huggingface.co/t/flagged-as-abusive-false-positive-on-zerogpu-space-cannot-restart/176554) > - [HF Content Policy](https://huggingface.co/content-policy) > > If there is no such warning text, I would not lead with this hypothesis. > **6. What I would include if contacting HF support/staff** > > If the UI does not show useful logs and both Restart and Factory rebuild fail, I would collect a small evidence bundle instead of repeatedly pressing restart. > > Useful evidence: > > | Item | Example | > | --- | --- | > | Space URL | `https://huggingface.co/spaces/Ark-kun/tangent` | > | Visibility | Private | > | Exact failed action | Restart / Factory rebuild / new commit / hardware change | > | Error text | `503. Something went wrong when restarting this Space.` | > | Root request ID | `Root=...` | > | UTC timestamp | Exact time when the error appeared | > | Current UI status | Paused / Building / Starting / etc. | > | Build logs | Whether they updated after restart/factory rebuild | > | Container logs | Whether they updated after restart/factory rebuild | > | Last visible log timestamp | Helps show whether logs are stale | > | Warning banner text | Only if visible | > | Safe screenshot | Only if it does not expose secrets/tokens/private data | > > Short version to send: > > > My private Space cannot be restarted. Restart and Factory rebuild both return 503. No new Build/Container logs appear after the action. Here is the Space URL, Root request ID, UTC timestamp, current UI status, and the last visible log timestamps. Could you check whether the Space is stuck in scheduler/runtime-control/policy state? > > Important: do not paste tokens, secrets, private credentials, or sensitive log lines publicly. > **7. Optional fallback: CLI/API, but I would not make it the first step here** > > The UI checks above should probably come first, especially because this is a private Space and CLI/API access requires authentication. > > If the UI is not enough, the owner can also use the Hub API or CLI. This is more precise, but it requires a token with access to the private Space. > > Official docs: > > - [Manage your Space: logs via `fetch_space_logs()` and CLI](https://huggingface.co/docs/huggingface_hub/guides/manage-spaces#debug-a-failing-space-by-reading-its-logs) > - [Managing Space runtime: `get_space_runtime`, `fetch_space_logs`, `restart_space`](https://huggingface.co/docs/huggingface_hub/package_reference/space_runtime) > - [User access tokens](https://huggingface.co/docs/hub/security-tokens) > > Optional CLI checks: > > ```bash > hf spaces logs Ark-kun/tangent --build -n 100 > hf spaces logs Ark-kun/tangent -n 100 > > ``` > > Optional Python check: > > ```python > from huggingface_hub import HfApi > > api = HfApi(token="hf_xxx") # do not post this token publicly > rt = api.get_space_runtime("Ark-kun/tangent") > > print("stage:", rt.stage) > print("hardware:", rt.hardware) > print("requested_hardware:", rt.requested_hardware) > print("raw:", rt.raw) > > ``` > > For a public forum thread, I would only paste the non-sensitive parts, and redact anything private. So my practical suggestion would be: 1. Use the Space UI first. 2. Open **Logs** and check both **Build** and **Container** tabs. 3. Note whether either log gets a new timestamp after Restart / Factory rebuild. 4. Check Files / `README.md` for SDK/config issues. 5. Check Settings and any warning banner. 6. If no logs move and both restart actions return 503, collect the Root ID + UTC timestamp + UI state and ask HF support/staff to inspect the Space state from their side. The most important distinction is: - **Logs show a concrete error** → likely still worth debugging from the repo/config side. - **No new logs appear at all** → likely not enough evidence for code debugging; HF-side inspection may be needed. --- _[View the full topic](https://discuss.huggingface.co/t/cannot-restart-my-private-space-503-something-went-wrong-when-restarting-this-space/177235)._