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: 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 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
# and, if present in raw metadata:
abuse / moderation / detector / scanner information
I would interpret the result roughly like this:
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:
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)
the important runtime state was:
{
"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:
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
Initially the visible symptom was essentially:
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:
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
showed:
{
"stage": "PAUSED",
"hardware": {
"current": null,
"requested": "zero-a10g"
},
"errorMessage": "Flagged as abusive"
}
The author reported that:
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
The reported behavior was very similar:
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:
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
There the runtime showed:
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:
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:
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 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:
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:
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 lists:
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 separately lists:
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
The reported detector information there was:
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:
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 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:
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:
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(), and the CLI has equivalent commands:
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:
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:
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.