Hmm… If the symptom is really “stuck in D
”, 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 D
.
503
alone is generic.
D
- restart failing + factory rebuild failing + commits not dispatching a new build is the more important pattern.
| 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 D
and no build is being dispatched, I would stop pushing repeated commits and first inspect the 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.
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 d 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 D / 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.
If there is no moderation/scanner message, but:
Space remains D
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.
If logs update, then debug it as a normal Space issue.
Common checks:
127.0.0.1
instead of 0.0.0.0
app_port
mismatchEXPOSE
mismatchFor 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
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 URLI would avoid:
503
automatically means an abuse flagA small duplicate/minimal Space test can be useful, but if the issue is account-side or lifecycle-side, many duplicates may just add noise.
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/D-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 D
, 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.