# Space stuck on "Paused" status and returning Error 503 on Factory Rebuild

**URL:** <https://discuss.huggingface.co/t/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild/179216>\
**Category:** Spaces\
**Created:** [August 24, 2026, 12:29pm UTC](https://discuss.huggingface.co/t/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild/179216 "2026-08-24T12:29:31Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![elhelihey](https://avatars.discourse-cdn.com/v4/letter/e/a587f6/32.png) [@elhelihey](https://discuss.huggingface.co/u/elhelihey)\
**Post date:** [August 24, 2026, 12:29pm UTC](https://discuss.huggingface.co/t/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild/179216/1 "2026-08-24T12:29:31Z")

</div>

Hello Hugging Face Support Team,

My Space has been stuck on “Paused” since yesterday. Whenever I try to unpause it, the button doesn’t respond. I also tried to trigger a “Factory Rebuild”, but it immediately fails and gives me a **503 Service Unavailable** error.

It seems like the node hosting my Space is unresponsive. Here is the Request ID from the error screen: **Request ID:** `Root=1-6a8c3842-6e4f528f6119e9903457c926`

Could you please help me kill the stuck process or migrate the Space to a healthy node so I can restart it?

Thank you in advance!

---

<div class="post-metadata">

**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:** [August 25, 2026, 3:30am UTC](https://discuss.huggingface.co/t/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild/179216/2 "2026-08-25T03:30:20Z")

</div>

Probably, there’s a good chance this Space has been flagged (possibly falsely). I think you’ll most likely have to contact HF Support at `website@huggingface.co`:

* * *

Your “stuck node / stuck process” hypothesis is still possible, but I would not assume that is the root cause yet.

The part that stands out to me is the combination of:

```plaintext
Space: PAUSED
Resume/Unpause: does not work
Factory Rebuild: immediately returns 503
Request ID: Root=...

```

A normal manually paused Space is supposed to be restartable by its owner, and Hugging Face also exposes normal restart / factory-reboot operations through the API and CLI. See the [Spaces documentation](https://huggingface.co/docs/hub/spaces) and the [`hf spaces restart` documentation](https://huggingface.co/docs/huggingface_hub/en/guides/cli).

So before spending much time debugging Docker, changing files, or trying to force a new build, I would first check the **Space runtime state**. That is a very cheap check, and in several recent cases it exposed a moderation/abuse hold that the UI only presented as a generic `503`.

For example:

```python
from huggingface_hub import HfApi

api = HfApi()

runtime = api.get_space_runtime("USERNAME/SPACE_NAME")

print(runtime.raw)

```

`get_space_runtime()` is a normal Hugging Face Hub API operation; the relevant API is documented under [Managing your Space runtime](https://huggingface.co/docs/huggingface_hub/main/en/package_reference/space_runtime).

The most useful things to look for are approximately:

```plaintext
stage
hardware.current
hardware.requested
errorMessage

# and, if present in raw metadata:
abuse / moderation / detector / scanner information

```

I would interpret the result roughly like this:

```plaintext
PAUSED + restart/factory rebuild -> 503
              |
              v
       inspect runtime state
              |
       +------+---------------------------+
       | |
 explicit abuse/flag no explicit flag
 message message
       | |
       v v
 HF-side review does a new build/run
 rather than ordinary actually start?
 Docker debugging |
                                +-------+-------+
                                | |
                               no yes
                                | |
                                v v
                         lifecycle / normal build /
                         scheduler / container /
                         backend issue app debugging

```

So, if the runtime actually says something like:

```plaintext
errorMessage: Flagged as abusive

```

I would stop treating this as an ordinary application crash for the moment and send the Space URL, Request ID, timestamp, and runtime output to HF.

If there is **no flag/error message** , and a restart/factory rebuild still never produces any fresh Build or Container logs, then your original “something is stuck on the HF side” theory becomes much more relevant. At that point, whether the internal problem is a stale runtime, scheduler state, allocation issue, or a bad node is something HF staff are in a much better position to determine from the `Root=...` request trace.

If fresh build/container logs _do_ appear, then I would switch back to ordinary repo/runtime debugging.

> **Why I suspect a flag / false-positive branch here**
>
> There are several recent public cases where a Space looked externally like an ordinary restart/503 problem, but the actual state was a Hugging Face-side abuse/moderation hold.
> 
> ### Very close example: Factory Rebuild 503 → runtime says `Flagged as abusive`
> 
> In this recent thread:
> 
> [Space stuck: factory rebuild returns 503 (Request ID included)](https://discuss.huggingface.co/t/space-stuck-factory-rebuild-returns-503-request-id-included/178509/2)
> 
> the important runtime state was:
> 
> ```json
> {
> "stage": "PAUSED",
> "hardware": {
> "current": null,
> "requested": "cpu-basic"
> },
> "errorMessage": "Flagged as abusive"
> }
> 
> ```
> 
> The useful comparison is not simply “both produced HTTP 503”.
> 
> The useful comparison is:
> 
> ```plaintext
> PAUSED
> +
> ordinary recovery controls fail
> +
> generic UI error
> +
> runtime API exposes a different HF-side state
> 
> ```
> 
> That is quite close to the symptoms you describe.
> 
> ### Generic restart error outside, moderation reason inside the API
> 
> Another particularly relevant case is:
> 
> [Space flagged as “abusive, reason trojan proxy” need help unblocking](https://discuss.huggingface.co/t/space-flagged-as-abusive-reason-trojan-proxy-need-help-unblocking/176099)
> 
> Initially the visible symptom was essentially:
> 
> ```plaintext
> Something went wrong when restarting this Space.
> Request ID: Root=...
> 
> ```
> 
> The author also reported no useful Build/Container log errors and that Factory Reset did not solve it.
> 
> Later, the HF API showed that the Space was actually paused with:
> 
> ```plaintext
> Flagged as abusive, reason trojan proxy on :7860
> 
> ```
> 
> An HF staff member replied in that thread acknowledging both the forum post and the support email and suggested following up through the support email.
> 
> This does **not** mean your Space has the same `trojan proxy` reason. It only demonstrates that a generic restart failure can hide a much more specific server-side moderation state.
> 
> ### A flag can prevent all the normal recovery attempts from doing anything useful
> 
> Another report:
> 
> [“Flagged as abusive” false positive on ZeroGPU Space — cannot restart](https://discuss.huggingface.co/t/flagged-as-abusive-false-positive-on-zerogpu-space-cannot-restart/176554)
> 
> showed:
> 
> ```json
> {
> "stage": "PAUSED",
> "hardware": {
> "current": null,
> "requested": "zero-a10g"
> },
> "errorMessage": "Flagged as abusive"
> }
> 
> ```
> 
> The author reported that:
> 
> ```plaintext
> Restart
> Factory rebuild
> hardware changes
> commits
> 
> ```
> 
> all failed to restore the Space or start a new build.
> 
> That is why I would first determine whether there is a Space-level hold before repeatedly modifying the repository.
> 
> ### Another useful case: plausible app bugs existed, but the final answer was still a policy hold
> 
> This one is also instructive:
> 
> [Restart error 503. Factory reset. No rebuild. Same with other space](https://discuss.huggingface.co/t/restart-error-503-factory-reset-no-rebuild-same-with-other-space/173779)
> 
> The reported behavior was very similar:
> 
> ```plaintext
> worked normally before
> -> suddenly PAUSED
> -> Restart immediately 503
> -> Factory Reboot immediately 503
> -> new commit does not start a rebuild
> 
> ```
> 
> There were plausible application-level things to investigate, but the author later posted the response received from HF: their Spaces had triggered automated detection systems and HF had classified them under the platform-abuse policy.
> 
> That is an important diagnostic lesson: **finding a possible bug in the application does not necessarily mean that bug explains why the Space control plane refuses to restart it.**
> 
> Those are two separate layers.

> **Why I would still not call the flag hypothesis confirmed**
>
> A `503` by itself is very non-specific.
> 
> Hugging Face Spaces can fail or stall at several layers:
> 
> ```plaintext
> repository / build
> |
> container startup
> |
> application health / port
> |
> machine allocation / scheduler
> |
> Space lifecycle/control plane
> |
> moderation / policy hold
> 
> ```
> 
> Several of those can eventually look like “Space unavailable” or a failed restart.
> 
> There is a useful recent counterexample:
> 
> [Spaces aren’t allocating for ZeroGPU tonight](https://discuss.huggingface.co/t/spaces-arent-allocating-for-zerogpu-tonight/178683)
> 
> There the runtime showed:
> 
> ```plaintext
> stage: APP_STARTING
> hardware.current: null
> errorMessage: null
> 
> ```
> 
> and an HF staff member explicitly said:
> 
> > Looks like it’s an infra issue.
> 
> It was subsequently resolved on the HF side.
> 
> So in particular:
> 
> ```plaintext
> hardware.current: null
> 
> ```
> 
> is **not** enough to diagnose an abuse flag.
> 
> The interesting discriminator is an actual error/abuse/moderation message, plus whether the builder/runtime is making forward progress.
> 
> There have also been plain platform/runtime-control reports such as:
> 
> [Space stuck in broken runtime-control state: build succeeds, but Factory reboot returns 503 and 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)
> 
> where the failure appears above the application layer even though no moderation cause was established.
> 
> Also, at the time of writing, the [HF status page](https://status.huggingface.co/) reports Spaces as operational. That makes a broad Spaces-wide outage less obvious, but it does **not** rule out a per-Space scheduler/runtime-control/moderation problem.
> 
> So I would describe the flag as **a strong hypothesis worth checking first** , not as an established root cause.

> **What I would send to HF Support**
>
> If this were my Space, I would send a small diagnostic packet rather than a long description.
> 
> Something like:
> 
> ```plaintext
> Space:
> https://huggingface.co/spaces/USERNAME/SPACE_NAME
> 
> HF username:
> USERNAME
> 
> Observed state:
> PAUSED
> 
> Failed operations:
> - Resume / Unpause
> - Restart
> - Factory Rebuild
> 
> Error:
> 503 Service Unavailable
> 
> Request ID:
> Root=...
> 
> Approximate failure time:
> YYYY-MM-DD HH:MM UTC
> 
> Runtime API output:
> <paste runtime.raw here>
> 
> Build logs after retry:
> new lines appeared / no new lines appeared
> 
> Container logs after retry:
> new lines appeared / no new lines appeared
> 
> Last known working time / commit:
> ...
> 
> Purpose of the Space:
> one or two sentences
> 
> ```
> 
> The `Root=...` request ID is especially worth preserving because it gives HF a server-side request/trace identifier to correlate with their internal logs.
> 
> I would also explicitly ask them to distinguish between the two branches:
> 
> ```plaintext
> Could you check whether this Space is stuck in the runtime/scheduler
> control plane, or whether it has been paused by a moderation/abuse
> flag? If it is flagged, could you tell me what needs to be changed or
> review the flag if appropriate?
> 
> ```
> 
> For general Spaces/Hub issues, the official [Spaces documentation](https://huggingface.co/docs/hub/spaces) lists:
> 
> ```plaintext
> website@huggingface.co
> 
> ```
> 
> as a contact route.
> 
> If HF confirms that this is specifically a **moderation decision** , rather than an ordinary infrastructure problem, the [Hugging Face Content Policy](https://huggingface.co/content-policy) separately lists:
> 
> ```plaintext
> safety@huggingface.co
> 
> ```
> 
> as the contact/contest route for content-moderation decisions.
> 
> So I would probably start with `website@huggingface.co` for the currently ambiguous Space/backend problem, then use the moderation route if HF confirms that is what happened.

> **A couple of things I would avoid doing before HF answers**
>
> ### 1. I would not delete arbitrary files based on guesses
> 
> There are public reports where a scanner apparently flagged repository material, the author removed the suspected file, but the Space-level flag still remained.
> 
> For example:
> 
> [Space flagged as abusive (false positive) — cannot restart after removing flagged file](https://discuss.huggingface.co/t/space-flagged-as-abusive-false-positive-cannot-restart-after-removing-flagged-file/173676)
> 
> The reported detector information there was:
> 
> ```plaintext
> Detector: RepoScanner
> Category: huggingface:tunnel
> Pattern: Cloudflare
> 
> ```
> 
> After the file was removed, Restart/Resume/Factory Rebuild reportedly still returned 503.
> 
> The lesson is **not** that your Space has anything to do with Cloudflare or tunnels.
> 
> The useful lesson is that, if a Space-level policy state has already been applied, changing random repository files may destroy useful evidence without clearing that state.
> 
> I would capture the runtime information first.
> 
> ### 2. `Flagged as abusive` would not by itself prove a false positive
> 
> There are three separate questions:
> 
> ```plaintext
> Was a flag applied?
> Why was it applied?
> Was that decision correct?
> 
> ```
> 
> The public runtime state may answer the first one while telling us almost nothing about the second or third.
> 
> Hugging Face’s current [Content Policy](https://huggingface.co/content-policy) says that moderation may be triggered from reports, internal signals, or automatic detection. It also lists several platform-abuse categories.
> 
> So if a runtime flag exists, I would simply describe it as:
> 
> ```plaintext
> an HF-side flag that needs review
> 
> ```
> 
> until HF tells you what triggered it.
> 
> ### 3. I would not infer the trigger purely from what kind of app this is
> 
> A networked app, bot, API server, browser integration, etc. is not by itself enough to establish which detector or policy rule was involved.
> 
> If HF gives you a concrete rule/reason, _then_ it becomes useful to compare the implementation with that rule and decide whether:
> 
> ```plaintext
> A. the detector misunderstood legitimate behavior,
> B. a particular component should be changed,
> C. or one hosting-sensitive component should be moved elsewhere.
> 
> ```
> 
> Until then, guessing at a particular dependency or feature is likely to be lower-information than getting the actual HF-side state.

> **If it turns out not to be a flag**
>
> Then I would keep your original backend/node hypothesis alive, but broaden it slightly from “the node is dead” to “the Space is stuck somewhere above the application layer”.
> 
> The cheapest distinction is whether a new retry actually creates new logs.
> 
> Hugging Face documents programmatic Build/Run log access via [`fetch_space_logs()`](https://huggingface.co/docs/huggingface_hub/main/guides/manage-spaces), and the CLI has equivalent commands:
> 
> ```bash
> hf spaces logs USERNAME/SPACE_NAME --build
> hf spaces logs USERNAME/SPACE_NAME
> 
> ```
> 
> Then the branches are roughly:
> 
> | Observation | More useful next branch |
> | --- | --- |
> | New build log appears and fails | Docker/dependency/build problem |
> | Build completes, then run log fails | container/app/runtime problem |
> | App says it is serving but public Space is 503 | health/port/proxy/routing branch |
> | No new build log at all after Factory Rebuild | builder dispatch / Space state / control-plane branch |
> | No new run log after successful build | allocation / container-start / scheduler branch |
> | Explicit `Flagged as abusive` | policy/review branch |
> | Explicit quota/permission message | account/quota branch |
> 
> This is also why I would not spend much time changing app code until you know the builder/container is actually being invoked.
> 
> If:
> 
> ```plaintext
> Factory Rebuild -> immediate 503
> new commit -> no build
> Build log -> unchanged
> Run log -> unchanged
> 
> ```
> 
> then the application may literally never get a chance to execute the proposed fix.
> 
> At that point, asking HF to inspect/reset/migrate the Space is reasonable; I would just give them the runtime state and trace ID so they can determine _which_ backend layer is actually stuck.

So my default path would be:

```plaintext
1. Save the Root request ID.
2. Inspect get_space_runtime(...).raw.
3. If it says "Flagged as abusive" -> stop ordinary rebuild debugging and ask HF to review it.
4. If there is no flag -> check whether a fresh Build/Run log is created.
5. If nothing new starts -> send the same evidence to HF as a lifecycle/scheduler/backend issue.
6. Only debug the application itself once the build/runtime pipeline is actually running again.

```

That should distinguish the useful branches with very little extra work, while still leaving open your original possibility that the Space really does need an HF-side runtime reset or migration.

---

<div class="post-metadata">

**Author:** ![meganariley](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/meganariley/32/56966_2.png) [@meganariley](https://discuss.huggingface.co/u/meganariley)\
**Post date:** [August 25, 2026, 8:59pm UTC](https://discuss.huggingface.co/t/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild/179216/3 "2026-08-25T20:59:37Z")

</div>

Hey @elhelihey it looks like you reached out to support earlier today. We’re reviewing your email and your Space and will follow up soon.

---

<div class="post-metadata">

**Author:** ![daspinaki2005](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/daspinaki2005/32/62643_2.png) [@daspinaki2005](https://discuss.huggingface.co/u/daspinaki2005)\
**Post date:** [August 25, 2026, 10:06pm UTC](https://discuss.huggingface.co/t/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild/179216/4 "2026-08-25T22:06:30Z")

</div>

This looks like a Hugging Face infrastructure issue rather than a problem with the Space itself. A 503 during Factory Rebuild usually indicates that the service or the node handling the Space is temporarily unavailable.

I’d recommend checking the Hugging Face Status page first and trying again after some time. If the Space remains stuck on “Paused,” contacting Hugging Face Support with the Request ID would be the best option so they can restart or migrate the Space.