Error fix of the 503 loop

🤗Transformers
1

Title: Space stuck in 503 loop — restart and commits not working

Body:

My Space is stuck in a 503 error and cannot be restarted. I have tried:

  • Clicking “Restart Space” and “Factory Rebuild” from the UI
  • Pushing multiple new commits (10–16 minutes ago)

None of these have triggered a rebuild. The Space remains paused.

Request ID: Root=1-6a3cf6e6-7fc29a29189ed6bc5e04fc5b
Space URL: [paste your Space URL here]

Could you please manually trigger a restart or clear the container state? Thank you.

2

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:

/static-proxy?url=https%3A%2F%2Fstatus.huggingface.co%2F%3C%2Fa%3E%3C%2Fp%3E

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:

  1. Is the Space actually building?
  2. Are build logs updating?
  3. Are container logs updating?
  4. Is the runtime API showing PAUSED only, or also an errorMessage?
  5. Does the runtime output mention an abuse/scanner/policy reason?
  6. If not, is this a builder/lifecycle stuck state?
  7. 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.

/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fflagged-as-abusive-false-positive-on-zerogpu-space-cannot-restart%2F176554%3C%2Fa%3E%3C%2Fp%3E

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.

/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fspace-flagged-as-abusive-false-positive-cannot-restart-after-removing-flagged-file%2F173676%3C%2Fa%3E%3C%2Fp%3E

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

/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fspace-flagged-as-abusive-reason-trojan-proxy-need-help-unblocking%2F176099%3C%2Fa%3E%3C%2Fp%3E

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.

/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fspace-flagged-as-abusive-by-cloudflare-rule-files-removed-still-paused-and-restart-fails%2F177057%3C%2Fa%3E%3C%2Fp%3E

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.

/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdocker-space-stuck-in-build-queued-immediately-paused-account-3ol1v%2F176589%3C%2Fa%3E%3C%2Fp%3E

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.

/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2F503-cant-rebuild-my-space-its-always-paused-or-503%2F174302%3C%2Fa%3E%3C%2Fp%3E

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.