{"slug": "space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild", "title": "Space stuck on \"Paused\" status and returning Error 503 on Factory Rebuild", "summary": "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.", "body_md": "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`\n\n:\n\nYour “stuck node / stuck process” hypothesis is still possible, but I would not assume that is the root cause yet.\n\nThe part that stands out to me is the combination of:\n\n```\nSpace: PAUSED\nResume/Unpause: does not work\nFactory Rebuild: immediately returns 503\nRequest ID: Root=...\n```\n\nA 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).\n\nSo 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`\n\n.\n\nFor example:\n\n``` python\nfrom huggingface_hub import HfApi\n\napi = HfApi()\n\nruntime = api.get_space_runtime(\"USERNAME/SPACE_NAME\")\n\nprint(runtime.raw)\n```\n\n`get_space_runtime()`\n\nis 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).\n\nThe most useful things to look for are approximately:\n\n```\nstage\nhardware.current\nhardware.requested\nerrorMessage\n\n# and, if present in raw metadata:\nabuse / moderation / detector / scanner information\n```\n\nI would interpret the result roughly like this:\n\n``` php\nPAUSED + restart/factory rebuild -> 503\n              |\n              v\n       inspect runtime state\n              |\n       +------+---------------------------+\n       |                                  |\n explicit abuse/flag                  no explicit flag\n message                              message\n       |                                  |\n       v                                  v\n HF-side review                does a new build/run\n rather than ordinary          actually start?\n Docker debugging                      |\n                                +-------+-------+\n                                |               |\n                               no              yes\n                                |               |\n                                v               v\n                         lifecycle /       normal build /\n                         scheduler /       container /\n                         backend issue     app debugging\n```\n\nSo, if the runtime actually says something like:\n\n```\nerrorMessage: Flagged as abusive\n```\n\nI 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.\n\nIf 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=...`\n\nrequest trace.\n\nIf fresh build/container logs *do* appear, then I would switch back to ordinary repo/runtime debugging.\n\nSo my default path would be:\n\n```\n1. Save the Root request ID.\n2. Inspect get_space_runtime(...).raw.\n3. If it says \"Flagged as abusive\" -> stop ordinary rebuild debugging and ask HF to review it.\n4. If there is no flag -> check whether a fresh Build/Run log is created.\n5. If nothing new starts -> send the same evidence to HF as a lifecycle/scheduler/backend issue.\n6. Only debug the application itself once the build/runtime pipeline is actually running again.\n```\n\nThat 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.", "url": "https://wpnews.pro/news/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild", "canonical_source": "https://discuss.huggingface.co/t/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild/179216#post_2", "published_at": "2026-08-25 03:30:20+00:00", "updated_at": "2026-08-25 03:43:46.299107+00:00", "lang": "en", "topics": ["ai-infrastructure"], "entities": ["Hugging Face", "Hugging Face Hub", "HfApi", "get_space_runtime"], "alternates": {"html": "https://wpnews.pro/news/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild", "markdown": "https://wpnews.pro/news/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild.md", "text": "https://wpnews.pro/news/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild.txt", "jsonld": "https://wpnews.pro/news/space-stuck-on-paused-status-and-returning-error-503-on-factory-rebuild.jsonld"}}