Docker Space stuck in "Build Queued" / immediately "Paused" — account 3oL1v

Spaces
1

Hello,

My Docker Spaces (3oL1v/botsam and 3oL1v/botsam-dry) have been stuck in “Build Queued” / immediately flipping to “Paused” for over 24 hours. All restart, factory-rebuild, and resume actions via the UI and API return HTTP 503.

Details:

  • Account: 3oL1v
    • Email: verified
      • Billing: $0, no payment method needed
        • HF status page: all systems green
          • Last push (force): commit 95f3fab, 2026-06-06 ~00:27 UTC
            • SDK: Docker, app_port: 8092
          • The Spaces never start building — they go directly from “Build Queued” to “Paused”. This happens on both Spaces. No code change fixes it because the builder never runs.
        • Could HF staff check whether there is an account-level restriction on 3oL1v that is preventing Docker Spaces from building? Thank you.
2

Hmm, false positive or true positive, I think this probably will not go anywhere until HF Support (website@huggingface.co) looks at it first:

I would not treat this as a normal Dockerfile / app_port / app-startup issue yet.

The key sentence in your report is this:

The Spaces never start building — they go directly from “Build Queued” to “Paused”. This happens on both Spaces. No code change fixes it because the builder never runs.

If the builder really never starts, then this is probably above the app-code layer. It may still be a Docker-builder / scheduler / Space-lifecycle problem rather than a moderation problem, but it does not look like the usual “container started and then crashed” class of issue.

Short answer

My practical recommendation would be:

  1. Contact HF Support first: website@huggingface.co
  2. Do not spend too much time repeatedly changing the repo yet if the builder never actually starts.
  3. Treat this as a Space lifecycle / Docker builder / account-side / possible moderation-lock bucket until HF checks it from their side.

I would not say “this is definitely an abuse flag” from outside. But I would also not dismiss that possibility, because similar public cases have existed.

Why this looks different from a normal Docker startup problem

For Docker Spaces, the normal app-side things to check are still real:

  • sdk: docker
  • app_port
  • server binding to 0.0.0.0
  • container health / startup crash
  • missing environment variables
  • dependency install failure
  • app never becoming healthy

HF’s Docker Spaces docs describe the normal Docker setup: selecting Docker sets sdk: docker in the Space README YAML, and the default exposed port can be changed with app_port:

Docker Spaces — Hugging Face docs

Those are important when the build actually runs and the container starts or fails.

But your report is different:

Observation Why it matters
Build Queued only Suggests the build worker may not be actually running
Immediately flips to Paused Not typical for a plain Python exception inside the app
Restart / resume / factory rebuild fail Not just a normal app reload problem
Two Docker Spaces affected Less likely to be one bad Dockerfile typo
“Builder never runs” Strongly points above the app-code layer
Code changes do not help Expected if no build is actually dispatched

So the important distinction is:

Case What usually happens
Dockerfile / dependency failure Build logs usually show something
App crash after build Container logs usually show something
Wrong port / unhealthy container Build may complete, then runtime fails
Builder / scheduler / lifecycle / lock issue Logs may stay empty or only show queueing
Moderation / abuse / policy lock May appear as PAUSED, restart failure, or API-level error depending on where you look

Your report sounds closer to the last two categories than to the first three.

PAUSED, restart failure, and HTTP 503 are not the same observation

One source of confusion is that several different layers can collapse into similar UI symptoms.

I would separate these:

Term Meaning
PAUSED on the Space page The visible Space lifecycle state
Restart failure toast The Settings/UI says something like “Something went wrong when restarting this Space”
Actual HTTP 503 Observed through API, CLI, browser DevTools, or a precise error response
raw.errorMessage / moderation reason Runtime/API metadata, if visible
Empty build logs The builder may not have started
Container logs with traceback The app actually ran and crashed

HF’s own docs describe pause/sleep as part of the normal Space lifecycle. On free hardware, a Space can sleep after inactivity; owners can also manually pause a Space, and a paused Space stops executing until manually restarted:

Spaces Overview — Lifecycle management

So PAUSED alone is not enough to diagnose anything.

Likewise, 503 alone is not specific. A public forum reply explains that “503 – Something went wrong when restarting this Space” can be a generic front-end/backend failure surface for several cases: build failure, container crash, or container never becoming healthy:

My space was paused and 503 when restart

But the combination matters:

Build Queued only + no real build logs + failed restart/resume/factory rebuild + multiple Docker Spaces

That combination is much more suspicious than just “503 when restarting”.

Public cases that look relevant

I would group the public cases into several buckets. This is why I would avoid making a final diagnosis from the UI alone.

Timeline / pattern table

Public case Visible pattern What it suggests
Spaces Docker Build Pauses and 503 Error on Restart Docker Space paused immediately, restart gives 503, logs only show Build queued Builder/scheduler/Space-state issue can look like this
My space was paused and 503 when restart Generic 503 restart failure 503 is not diagnostic by itself; app/container failures can also produce it
Space flagged as abusive (false positive) - cannot restart after removing flagged file RepoScanner, huggingface:tunnel, Cloudflare, paused Space, restart/resume/factory rebuild all return 503 Abuse / false-positive flags can also surface as restart/factory-rebuild failures
Space flagged as “abusive, reason trojan proxy” need help unblocking UI only showed restart failure, logs had no clear error; API later showed moderation pause and Flagged as abusive UI may hide the actual moderation reason
Repeated false-positive abuse-handler flags on new Space creation New Docker Space + first push triggered runtime.abuse.detector = "abuse-handler" and Blocked by abuse-handler by rule: Cloudflare New Docker Space creation / first push can be part of the trigger pattern in some public reports
Space flagged as abusive by Cloudflare rule (false positive) Flagged as abusive, Blocked by abuse-handler by rule: Cloudflare, immediately after first build queue Shows another Cloudflare-rule false-positive style report
“Flagged as abusive” false positive on ZeroGPU Space — cannot restart Runtime API reported stage: PAUSED and errorMessage: Flagged as abusive; restart, factory rebuild, hardware change, and commits did not help When a Space is locked/flagged, repo changes may not trigger a new build
Space restart failed - infrastructure issue affecting multiple Spaces Multiple Spaces stuck in PAUSED, restart failure, no new logs Similar symptoms can also be infrastructure/platform-side, not necessarily moderation
Stuck at space problem - HF staff reply Similar issue reported internally; infra team working on it Some stuck / restart-failure clusters have been infra-side

The point is not that all of these are the same bug.

The point is that the same surface symptoms can belong to different buckets:

Bucket Can look like PAUSED? Can look like restart failure / 503? Can have no useful logs?
Normal pause / sleep Yes Usually restart should work Usually not relevant
App/container crash Sometimes Yes Usually container logs exist
Wrong port / health check Sometimes Yes Build logs usually exist
Docker builder / scheduler stuck Yes Yes Yes
Space record / lifecycle state issue Yes Yes Yes
Infrastructure/platform issue Yes Yes Yes
Abuse/moderation/policy lock Yes Yes Often yes from the public UI

That is why I would not conclude too much from PAUSED or 503 alone.

But I would take “builder never runs” very seriously.

Why a false-positive / moderation-lock path is at least plausible

There are public forum examples where the final reason was clearly an abuse/moderation flag, but the user-facing symptom was not initially very clear.

For example:

So I would keep a moderation/false-positive lock as one possible bucket.

But I would not call it confirmed from the outside.

Why an infra / lifecycle bucket is also plausible

There are also public reports where multiple Spaces were stuck in PAUSED, could not be restarted, and showed no new logs, and the discussion treated it as infrastructure/platform-side rather than app-code-side:

Space restart failed - infrastructure issue affecting multiple Spaces

There was also a staff reply in a related stuck-Spaces thread saying that a similar issue had already been reported internally and that the infra team was working on it:

Stuck at space problem - #3 by hysts

So the public evidence supports this cautious framing:

This may be a lifecycle / builder / account-side / moderation-lock issue. It is probably not something that can be reliably fixed by editing the app code if the builder never starts.

That is weaker than “you were banned”, but stronger than “try changing the port”.

Why I would contact HF Support before more repo changes

If this were a normal Docker startup failure, I would expect one of these:

  • build logs showing dependency installation failure
  • container logs showing a traceback
  • health check / wrong-port symptoms after build
  • a clear failure after the image is built

But your report says the builder does not run at all.

In that state, more commits may not add much signal. If the build worker never picks up the job, changing the Dockerfile will not prove much. It can also make the timeline noisier.

For this type of issue, HF can see things that forum users cannot:

HF-side visibility Why it matters
Space lifecycle state Whether the Space is just paused, stuck, or blocked
Builder queue / dispatch state Whether a build job is actually being picked up
Internal request IDs Why restart / resume / factory rebuild failed
Account / namespace-level flags Whether this affects more than one Space
Moderation / abuse-handler state Whether an automated flag exists
Backend logs Whether the 503 is from builder, scheduler, router, or policy gate

So I would send the case to website@huggingface.co and wait for the backend-side check.

What I would avoid assuming

I would avoid these conclusions unless HF confirms them:

Too strong Safer wording
“This is definitely an abuse false positive.” “This resembles some public false-positive / moderation-lock cases.”
“This is definitely an account ban.” “Account-side or namespace-side state is possible because multiple Docker Spaces are affected.”
“503 means abusive.” “503 is a generic restart/backend failure surface.”
“It is a Dockerfile bug.” “Dockerfile/app-port issues are possible only if the build/container actually runs.”
“Status page is green, so it cannot be HF-side.” “A green status page does not rule out account/Space-specific lifecycle or builder issues.”

Practical next step

Since you already have a concise report with the account, affected Space IDs, commit, SDK, app_port, and the fact that UI/API restart/factory rebuild/resume return 503, I would send it to:

website@huggingface.co

If HF explicitly tells you this is a moderation decision, then Hugging Face’s Content Policy also has a separate contest route for moderation decisions involving disabled content or account suspension:

Hugging Face Content Policy — How you can contest a moderation decision

But for operational unblocking of a Space, the public forum pattern usually points first to website@huggingface.co.

Bottom line

My read is:

This does not look like a normal repo-side Docker error if the builder never starts.
PAUSED alone is not diagnostic, and 503 alone is not diagnostic, but Build Queued only + immediate Paused + failed restart/resume/factory rebuild across multiple Docker Spaces points above the application layer.
Similar public cases include builder/scheduler stuck states, infrastructure-side problems, and false-positive abuse/moderation locks.
Because HF needs backend-side visibility to distinguish those, contacting website@huggingface.co first is the right path.