Space stuck on "Paused" status and returning Error 503 on Factory Rebuild

A Hugging Face Space stuck in 'Paused' status with a failing Factory Rebuild returning Error 503 is likely flagged for moderation, according to a community response. The advice is to inspect the Space runtime state via the Hugging Face Hub API's get_space_runtime() method, which may reveal an explicit abuse flag; if flagged, users should contact Hugging Face support at website@huggingface.co rather than debugging the application. If no flag appears, the issue may be a lifecycle or backend problem on Hugging Face's side, and users should provide the Request ID and runtime output to support.

Probably, there’s a good chance this Space has been flagged possibly falsely . I think you’ll most likely have to contact HF Support at website@huggingface.co : Your “stuck node / stuck process” hypothesis is still possible, but I would not assume that is the root cause yet. The part that stands out to me is the combination of: Space: PAUSED Resume/Unpause: does not work Factory Rebuild: immediately returns 503 Request ID: Root=... A normal manually paused Space is supposed to be restartable by its owner, and Hugging Face also exposes normal restart / factory-reboot operations through the API and CLI. See the Spaces documentation https://huggingface.co/docs/hub/spaces and the hf spaces restart documentation https://huggingface.co/docs/huggingface hub/en/guides/cli . So before spending much time debugging Docker, changing files, or trying to force a new build, I would first check the Space runtime state . That is a very cheap check, and in several recent cases it exposed a moderation/abuse hold that the UI only presented as a generic 503 . For example: python from huggingface hub import HfApi api = HfApi runtime = api.get space runtime "USERNAME/SPACE NAME" print runtime.raw get space runtime is a normal Hugging Face Hub API operation; the relevant API is documented under Managing your Space runtime https://huggingface.co/docs/huggingface hub/main/en/package reference/space runtime . The most useful things to look for are approximately: stage hardware.current hardware.requested errorMessage and, if present in raw metadata: abuse / moderation / detector / scanner information I would interpret the result roughly like this: php PAUSED + restart/factory rebuild - 503 | v inspect runtime state | +------+---------------------------+ | | explicit abuse/flag no explicit flag message message | | v v HF-side review does a new build/run rather than ordinary actually start? Docker debugging | +-------+-------+ | | no yes | | v v lifecycle / normal build / scheduler / container / backend issue app debugging So, if the runtime actually says something like: errorMessage: Flagged as abusive I would stop treating this as an ordinary application crash for the moment and send the Space URL, Request ID, timestamp, and runtime output to HF. If there is no flag/error message , and a restart/factory rebuild still never produces any fresh Build or Container logs, then your original “something is stuck on the HF side” theory becomes much more relevant. At that point, whether the internal problem is a stale runtime, scheduler state, allocation issue, or a bad node is something HF staff are in a much better position to determine from the Root=... request trace. If fresh build/container logs do appear, then I would switch back to ordinary repo/runtime debugging. So my default path would be: 1. Save the Root request ID. 2. Inspect get space runtime ... .raw. 3. If it says "Flagged as abusive" - stop ordinary rebuild debugging and ask HF to review it. 4. If there is no flag - check whether a fresh Build/Run log is created. 5. If nothing new starts - send the same evidence to HF as a lifecycle/scheduler/backend issue. 6. Only debug the application itself once the build/runtime pipeline is actually running again. That should distinguish the useful branches with very little extra work, while still leaving open your original possibility that the Space really does need an HF-side runtime reset or migration.