{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihn4hrh2beoe6anzsx2gjqssdqivzlsgigwphcgbltggjcw22ypuq",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mnoojfgkcdo2"
  },
  "path": "/t/docker-space-stuck-in-build-queued-immediately-paused-account-3ol1v/176589#post_2",
  "publishedAt": "2026-06-07T07:37:22.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "Docker Spaces — Hugging Face docs",
    "Spaces Overview — Lifecycle management",
    "My space was paused and 503 when restart",
    "Spaces Docker Build Pauses and 503 Error on Restart",
    "Space flagged as abusive (false positive) - cannot restart after removing flagged file",
    "Space flagged as “abusive, reason trojan proxy” need help unblocking",
    "Repeated false-positive abuse-handler flags on new Space creation",
    "Space flagged as abusive by Cloudflare rule (false positive)",
    "“Flagged as abusive” false positive on ZeroGPU Space — cannot restart",
    "Space restart failed - infrastructure issue affecting multiple Spaces",
    "Stuck at space problem - HF staff reply",
    "Stuck at space problem - #3 by hysts",
    "Hugging Face Content Policy — How you can contest a moderation decision"
  ],
  "textContent": "Hmm, false positive or true positive, I think this probably will not go anywhere until HF Support (`website@huggingface.co`) looks at it first:\n\n* * *\n\nI would not treat this as a normal Dockerfile / `app_port` / app-startup issue yet.\n\nThe key sentence in your report is this:\n\n> 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.\n\nIf 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.\n\n## Short answer\n\nMy practical recommendation would be:\n\n  1. **Contact HF Support first:** `website@huggingface.co`\n  2. **Do not spend too much time repeatedly changing the repo yet** if the builder never actually starts.\n  3. Treat this as a **Space lifecycle / Docker builder / account-side / possible moderation-lock bucket** until HF checks it from their side.\n\n\n\nI 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.\n\n## Why this looks different from a normal Docker startup problem\n\nFor Docker Spaces, the normal app-side things to check are still real:\n\n  * `sdk: docker`\n  * `app_port`\n  * server binding to `0.0.0.0`\n  * container health / startup crash\n  * missing environment variables\n  * dependency install failure\n  * app never becoming healthy\n\n\n\nHF’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`:\n\nDocker Spaces — Hugging Face docs\n\nThose are important when the build actually runs and the container starts or fails.\n\nBut your report is different:\n\nObservation | Why it matters\n---|---\n`Build Queued` only | Suggests the build worker may not be actually running\nImmediately flips to `Paused` | Not typical for a plain Python exception inside the app\nRestart / resume / factory rebuild fail | Not just a normal app reload problem\nTwo Docker Spaces affected | Less likely to be one bad Dockerfile typo\n“Builder never runs” | Strongly points above the app-code layer\nCode changes do not help | Expected if no build is actually dispatched\n\nSo the important distinction is:\n\nCase | What usually happens\n---|---\nDockerfile / dependency failure | Build logs usually show something\nApp crash after build | Container logs usually show something\nWrong port / unhealthy container | Build may complete, then runtime fails\nBuilder / scheduler / lifecycle / lock issue | Logs may stay empty or only show queueing\nModeration / abuse / policy lock | May appear as `PAUSED`, restart failure, or API-level error depending on where you look\n\nYour report sounds closer to the last two categories than to the first three.\n\n## `PAUSED`, restart failure, and HTTP 503 are not the same observation\n\nOne source of confusion is that several different layers can collapse into similar UI symptoms.\n\nI would separate these:\n\nTerm | Meaning\n---|---\n`PAUSED` on the Space page | The visible Space lifecycle state\nRestart failure toast | The Settings/UI says something like “Something went wrong when restarting this Space”\nActual HTTP 503 | Observed through API, CLI, browser DevTools, or a precise error response\n`raw.errorMessage` / moderation reason | Runtime/API metadata, if visible\nEmpty build logs | The builder may not have started\nContainer logs with traceback | The app actually ran and crashed\n\nHF’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:\n\nSpaces Overview — Lifecycle management\n\nSo `PAUSED` alone is not enough to diagnose anything.\n\nLikewise, `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:\n\nMy space was paused and 503 when restart\n\nBut the combination matters:\n\n> `Build Queued` only + no real build logs + failed restart/resume/factory rebuild + multiple Docker Spaces\n\nThat combination is much more suspicious than just “503 when restarting”.\n\n## Public cases that look relevant\n\nI would group the public cases into several buckets. This is why I would avoid making a final diagnosis from the UI alone.\n\n### Timeline / pattern table\n\nPublic case | Visible pattern | What it suggests\n---|---|---\nSpaces 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\nMy space was paused and 503 when restart | Generic `503` restart failure | `503` is not diagnostic by itself; app/container failures can also produce it\nSpace 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\nSpace 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\nRepeated 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\nSpace 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\n“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\nSpace 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\nStuck at space problem - HF staff reply | Similar issue reported internally; infra team working on it | Some `stuck` / restart-failure clusters have been infra-side\n\nThe point is not that all of these are the same bug.\n\nThe point is that the same surface symptoms can belong to different buckets:\n\nBucket | Can look like `PAUSED`? | Can look like restart failure / 503? | Can have no useful logs?\n---|---|---|---\nNormal pause / sleep | Yes | Usually restart should work | Usually not relevant\nApp/container crash | Sometimes | Yes | Usually container logs exist\nWrong port / health check | Sometimes | Yes | Build logs usually exist\nDocker builder / scheduler stuck | Yes | Yes | Yes\nSpace record / lifecycle state issue | Yes | Yes | Yes\nInfrastructure/platform issue | Yes | Yes | Yes\nAbuse/moderation/policy lock | Yes | Yes | Often yes from the public UI\n\nThat is why I would not conclude too much from `PAUSED` or `503` alone.\n\nBut I would take “builder never runs” very seriously.\n\n## Why a false-positive / moderation-lock path is at least plausible\n\nThere are public forum examples where the final reason was clearly an abuse/moderation flag, but the user-facing symptom was not initially very clear.\n\nFor example:\n\n  * In one case, a Space was flagged by `RepoScanner` with category `huggingface:tunnel` and pattern `Cloudflare`; after the user removed the flagged file, the abuse flag persisted and restart/resume/factory rebuild all returned 503:\nSpace flagged as abusive (false positive) - cannot restart after removing flagged file\n\n  * In another case, the visible UI only showed a restart failure and no build/container log errors, but the HF API later showed the Space was paused by moderation with `errorMessage: Flagged as abusive, reason trojan proxy on :7860`:\nSpace flagged as “abusive, reason trojan proxy” need help unblocking\n\n  * In another case, a new Docker Space reportedly triggered `runtime.abuse.detector = \"abuse-handler\"` and `Blocked by abuse-handler by rule: Cloudflare` very soon after first push:\nRepeated false-positive abuse-handler flags on new Space creation\n\n  * In another case, the runtime API reportedly returned `stage: PAUSED` and `errorMessage: Flagged as abusive`; restart, factory rebuild, hardware change, and commits all failed:\n“Flagged as abusive” false positive on ZeroGPU Space — cannot restart\n\n\n\n\nSo I would keep a moderation/false-positive lock as one possible bucket.\n\nBut I would not call it confirmed from the outside.\n\n## Why an infra / lifecycle bucket is also plausible\n\nThere 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:\n\nSpace restart failed - infrastructure issue affecting multiple Spaces\n\nThere 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:\n\nStuck at space problem - #3 by hysts\n\nSo the public evidence supports this cautious framing:\n\n> 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.\n\nThat is weaker than “you were banned”, but stronger than “try changing the port”.\n\n## Why I would contact HF Support before more repo changes\n\nIf this were a normal Docker startup failure, I would expect one of these:\n\n  * build logs showing dependency installation failure\n  * container logs showing a traceback\n  * health check / wrong-port symptoms after build\n  * a clear failure after the image is built\n\n\n\nBut your report says the builder does not run at all.\n\nIn 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.\n\nFor this type of issue, HF can see things that forum users cannot:\n\nHF-side visibility | Why it matters\n---|---\nSpace lifecycle state | Whether the Space is just paused, stuck, or blocked\nBuilder queue / dispatch state | Whether a build job is actually being picked up\nInternal request IDs | Why restart / resume / factory rebuild failed\nAccount / namespace-level flags | Whether this affects more than one Space\nModeration / abuse-handler state | Whether an automated flag exists\nBackend logs | Whether the 503 is from builder, scheduler, router, or policy gate\n\nSo I would send the case to `website@huggingface.co` and wait for the backend-side check.\n\n## What I would avoid assuming\n\nI would avoid these conclusions unless HF confirms them:\n\nToo strong | Safer wording\n---|---\n“This is definitely an abuse false positive.” | “This resembles some public false-positive / moderation-lock cases.”\n“This is definitely an account ban.” | “Account-side or namespace-side state is possible because multiple Docker Spaces are affected.”\n“503 means abusive.” | “503 is a generic restart/backend failure surface.”\n“It is a Dockerfile bug.” | “Dockerfile/app-port issues are possible only if the build/container actually runs.”\n“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.”\n\n## Practical next step\n\nSince 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:\n\n`website@huggingface.co`\n\nIf 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:\n\nHugging Face Content Policy — How you can contest a moderation decision\n\nBut for operational unblocking of a Space, the public forum pattern usually points first to `website@huggingface.co`.\n\n## Bottom line\n\nMy read is:\n\n> This does not look like a normal repo-side Docker error if the builder never starts.\n>  `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.\n>  Similar public cases include builder/scheduler stuck states, infrastructure-side problems, and false-positive abuse/moderation locks.\n>  Because HF needs backend-side visibility to distinguish those, contacting `website@huggingface.co` first is the right path.",
  "title": "Docker Space stuck in \"Build Queued\" / immediately \"Paused\" — account 3oL1v"
}