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

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:

Space: D
Resume/Un: does not work
Factory Rebuild: immediately returns 503
Request ID: Root=...

A normal manually d 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 and the hf spaces restart documentation.

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:

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.

The most useful things to look for are approximately:

stage
hardware.current
hardware.requested
errorMessage

abuse / moderation / detector / scanner information

I would interpret the result roughly like this:

D + 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:

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.

So my default path would be:

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.