Hmm… If the symptom is really “stuck in PAUSED”, my personal impression is that many of these cases do not get fixed until website@huggingface.co looks at them from the backend side. There are exceptions, of course, but I would treat this as a Space-state / lifecycle / possible moderation-lock issue first, not as a normal app crash. Details:
Small note first: the Space URL in the post is still a placeholder, so nobody outside HF can inspect the actual repo/logs yet. But as a general decision tree, I would debug this by separating 503 from PAUSED.
503 alone is generic.
PAUSED + restart failing + factory rebuild failing + commits not dispatching a new build is the more important pattern.
Quick decision tree
| What you observe |
Most likely bucket |
First useful check |
Next action |
| Build logs update and show an error |
Build failure |
Build log |
Fix dependency/Docker/build error |
| Container logs update and show a traceback |
App/runtime crash |
Container log |
Fix app crash, missing env vars, model download, etc. |
| App logs say it is running, but browser shows 503 |
Port/healthcheck/routing issue |
Port, host binding, app_port, healthcheck |
Fix Space config / server binding |
| Restart and Factory Rebuild fail, commits do not trigger build, logs do not update |
Space lifecycle / builder dispatch / stuck state |
Runtime API |
Likely needs HF-side inspection |
Runtime API says Flagged as abusive, abuse-handler, RepoScanner, Cloudflare, tunnel, proxy, etc. |
Moderation / scanner / policy lock |
Runtime API raw / errorMessage |
Email HF with evidence and ask for review |
| Many unrelated Spaces/users affected |
Platform incident |
HF status page |
Wait / follow incident |
So I would not conclude the root cause from 503 alone. But if the Space is really stuck in PAUSED and no build is being dispatched, I would stop pushing repeated commits and first inspect the runtime state.
First check: Space runtime state
Hugging Face documents runtime-management APIs in huggingface_hub, including get_space_runtime(), fetch_space_logs(), and restart_space():
https://huggingface.co/docs/huggingface_hub/en/package_reference/space_runtime
Try this locally:
from huggingface_hub import HfApi
api = HfApi(token="hf_xxx") # useful if the Space is private
runtime = api.get_space_runtime("OWNER/SPACE_NAME")
print("stage:", runtime.stage)
print("hardware:", runtime.hardware)
print("requested_hardware:", runtime.requested_hardware)
print("raw:", runtime.raw)
Or inspect the raw endpoint:
https://huggingface.co/api/spaces/OWNER/SPACE_NAME/runtime
With auth:
curl -H "Authorization: Bearer $HF_TOKEN" \
https://huggingface.co/api/spaces/OWNER/SPACE_NAME/runtime
Look for:
stage
hardware
requested_hardware
raw
errorMessage
abuse / moderation-related fields, if present
Important words to notice:
Flagged as abusive
abuse-handler
RepoScanner
Cloudflare
tunnel
proxy
trojan proxy
If any of those appear, this is probably not a normal build failure.
Practical branch guide
Branch A — Runtime output shows an abuse / moderation / scanner message
If the runtime output says something like:
Flagged as abusive
abuse-handler
RepoScanner
Cloudflare
tunnel
proxy
trojan proxy
then I would treat it as a HF-side review case.
That does not prove that you intentionally did anything wrong. It only means the Space may be paused by an automated scanner or policy mechanism, and more commits may not unlock it.
In that case, I would email website@huggingface.co with a compact, evidence-heavy report:
Subject: Space stuck in PAUSED / 503 loop - possible false positive or lifecycle lock
Space URL:
HF username:
Request ID:
Exact failed restart time, with timezone:
Runtime API output:
Build log status:
Container log status:
SDK type:
Hardware:
Last known working commit:
Recent changes:
What the Space does:
Why it is not a proxy/tunnel/relay/scraper/spam/abuse service:
Any suspicious files/dependencies already removed:
The key is to give HF enough backend correlation data: Space URL, Request ID, timestamp, and runtime output.
Branch B — No abuse message, but build never starts
If there is no moderation/scanner message, but:
Space remains PAUSED
Restart returns 503
Factory Rebuild returns 503
New commits do not trigger a build
Build logs do not update
Container logs do not update
then I would still treat this as a Space lifecycle / builder dispatch / stuck backend state issue.
Forum users usually cannot see the builder queue, lifecycle record, or backend restart error. This may still need HF-side inspection even if it is not an abuse/moderation case.
Branch C — Build/container logs do update
If logs update, then debug it as a normal Space issue.
Common checks:
- dependency install failure
- Python traceback
- missing secret / missing environment variable
- model download failing at startup
- startup taking too long
- server listening on the wrong port
- server binding to
127.0.0.1 instead of 0.0.0.0
- Docker
app_port mismatch
- Dockerfile
EXPOSE mismatch
- healthcheck/readiness problem
For Docker Spaces, the normal docs to check are:
https://huggingface.co/docs/hub/spaces-sdks-docker-first-demo
For Space metadata/configuration, including startup timeout:
https://huggingface.co/docs/hub/en/spaces-config-reference
Branch D — Possible platform incident
Also check:
https://status.huggingface.co/
A green status page does not rule out a single-Space or account-specific issue, but if there is an active Spaces / Spaces Proxy incident, changing your repo may not help.
Why I would not over-focus on the missing Space URL
The Space URL is needed for concrete debugging, so it is worth adding.
But even without it, the general decision tree is still useful:
- Is the Space actually building?
- Are build logs updating?
- Are container logs updating?
- Is the runtime API showing
PAUSED only, or also an errorMessage?
- Does the runtime output mention an abuse/scanner/policy reason?
- If not, is this a builder/lifecycle stuck state?
- If logs exist, what is the first real error?
So I would lightly ask for the URL, but I would not make the whole reply only about “please provide URL”.
Close public cases: similar pattern, not proof
These do not prove that this Space has the same cause. They only show why the runtime API output matters.
Flagged as abusive false positive on ZeroGPU Space
A public report described a Space where the runtime API showed a PAUSED stage and errorMessage: "Flagged as abusive". The user reported that restart, factory rebuild, hardware changes, and commits did not trigger a new build.
https://discuss.huggingface.co/t/flagged-as-abusive-false-positive-on-zerogpu-space-cannot-restart/176554
Why it matters:
- close to the
PAUSED + restart/factory/commit ineffective pattern
- suggests that UI actions may not clear a scanner/moderation lock
- runtime API gave more signal than the UI
RepoScanner / huggingface:tunnel / Cloudflare pattern
Another report said the Space was flagged with:
Detector: RepoScanner
Category: huggingface:tunnel
File: API_DOCUMENTATION.md
Pattern: Cloudflare
The user said they removed the flagged file, but the flag persisted and restart/resume/factory rebuild still returned 503.
https://discuss.huggingface.co/t/space-flagged-as-abusive-false-positive-cannot-restart-after-removing-flagged-file/173676
Why it matters:
- scanner flags may persist after commits
- removing a suspected file may not immediately unlock the Space
- Cloudflare/tunnel/proxy-related patterns can be sensitive
trojan proxy on :7860
Another report said the UI only showed a restart failure and no useful logs, but the API later showed:
errorMessage: Flagged as abusive, reason trojan proxy on :7860
https://discuss.huggingface.co/t/space-flagged-as-abusive-reason-trojan-proxy-need-help-unblocking/176099
Why it matters:
- the UI symptom was generic
- the API revealed the more specific branch
Cloudflare rule, files removed, still paused
There is also a report of a Space paused with:
Flagged as abusive
Blocked by abuse-handler by rule: Cloudflare
The user said they removed Cloudflare/relay/trycloudflare-related files and pushed a clean commit, but the Space remained PAUSED and restart/factory reboot still failed.
https://discuss.huggingface.co/t/space-flagged-as-abusive-by-cloudflare-rule-files-removed-still-paused-and-restart-fails/177057
Why it matters:
- close to “commits do not unlock the Space”
- useful precedent if the runtime output mentions Cloudflare/proxy/tunnel
Partially similar cases: lifecycle / builder / scheduler stuck
Docker Space stuck in build queue / immediately paused
A public report describes Docker Spaces stuck in Build Queued or immediately flipping to Paused, with restart/factory-rebuild/resume returning HTTP 503.
https://discuss.huggingface.co/t/docker-space-stuck-in-build-queued-immediately-paused-account-3ol1v/176589
Why it matters:
- build may never actually start
- app-code changes may not test anything if the builder is not dispatched
- Space lifecycle state can mimic app failure from the UI
This is a different bucket from moderation, but the visible symptoms can overlap.
Similar-looking but probably different cases
Gradio issue: paused Space, restart 503, commit not taking effect
There is a Gradio GitHub issue where a Space stayed paused, restart returned 503, and commits did not appear to take effect:
https://github.com/gradio-app/gradio/issues/12459
Why it is useful:
- similar surface symptom
- reminder not to jump straight to “abuse flag”
Why it may differ:
- may involve framework/app/runtime behavior rather than moderation
Docker/Streamlit-style health or routing issue
There are cases where logs show the app running, but the browser still returns 503. Those can be port, routing, healthcheck, or proxy-readiness issues rather than moderation locks.
https://discuss.huggingface.co/t/503-cant-rebuild-my-space-its-always-paused-or-503/174302
Why it is useful:
- counterexample to “all 503 loops are moderation”
- if logs are active, debug the app/container path first
Policy-sensitive patterns: why Cloudflare/proxy/tunnel wording matters
Hugging Face’s Content Policy includes platform-abuse language around restriction-bypass patterns such as Cloudflare Tunnel, TOR, proxies, VNC, Chrome Remote Server, and similar tools:
https://huggingface.co/content-policy
This does not mean the Space owner violated the policy.
It only means that if the runtime output or scanner output mentions Cloudflare, tunnel, proxy, relay, remote browser, VNC, or similar wording, it is worth explaining the legitimate use clearly when contacting HF.
A useful support phrasing would be:
My Space appears to be stuck in PAUSED and UI restart/factory rebuild both return 503. New commits do not dispatch a build. The runtime API shows the following output: ...
If this is an automated moderation or scanner flag, I believe it may be a false positive. The Space is used for ... It is not intended to provide proxy, tunnel, relay, scraping, spam, remote-browser, or restriction-bypass functionality.
Could someone review or clear the stuck Space state?
What I would avoid for now
I would avoid:
- pushing many empty commits before checking whether the builder is actually starting
- assuming
503 automatically means an abuse flag
- assuming it is only an app bug if no logs are updating
- deleting random files without checking the runtime output first
- posting tokens, secrets, full environment dumps, or private logs publicly
- creating many duplicate Spaces before knowing whether this is account/namespace/lifecycle-related
A small duplicate/minimal Space test can be useful, but if the issue is account-side or lifecycle-side, many duplicates may just add noise.
Final practical recommendation
I would treat this as a decision tree:
Does runtime API show abuse/scanner/policy wording?
-> Email HF with Space URL, Request ID, runtime output, timestamps, and legitimate-use explanation.
No abuse/scanner wording, but build never starts?
-> Still likely needs HF-side inspection; report it as a lifecycle/builder/PAUSED-state issue.
Build/container logs update?
-> Debug as a normal app/build/container/healthcheck issue.
Many Spaces affected?
-> Check HF status before changing repo code.
So yes, if the Space is genuinely stuck in PAUSED, my first serious path would be website@huggingface.co with the runtime API output attached. The Space URL is still needed for a concrete answer, but the general diagnosis path above should help decide whether this is app-level debugging or an HF-side Space-state issue.