My Hugging Face Space is stuck on Paused — Restart returns 503

Spaces
3

Hmm… it looks like there may have been an infrastructure issue, but this Space might be stopped for a separate reason too:thinking::

I checked the Space runtime state, and there is a more specific clue than the 503 itself:

{
  "stage": "PAUSED",
  "hardware": {
    "current": null,
    "requested": "cpu-basic"
  },
  "errorMessage": "Flagged as abusive"
}

So I would stop treating this as an ordinary Docker/build failure for now. The useful next step is probably to ask Hugging Face to review the flag, rather than repeatedly trying Restart / Factory Rebuild.

I would keep the Space URL, the Request ID you already posted, and the runtime JSON above, and send them to website@huggingface.co. In a very recent similar Forum case, HF staff specifically asked the user to email that address so they could take a closer look.

If this turns out to be a moderation decision that needs to be contested, HF’s Content Policy also lists safety@huggingface.co for moderation-related complaints/appeals.

The important limitation is that the runtime response does not expose the actual reason behind the flag. So I would not assume from this alone that Telegram, Stremio, a proxy feature, or any particular part of the application is the cause.

Why this may be separate from the infrastructure issue

The original symptoms — PAUSED, Restart/Factory Rebuild returning 503, and no new logs — can certainly look like a control-plane problem.

But there are public cases where essentially the same visible symptoms turned out to be a Space-level flag. For example, in this case, the runtime API eventually exposed:

Flagged as abusive, reason trojan proxy on :7860

That does not mean your Space has the same reason; your API response does not say that. It only shows why the runtime state is more useful here than the generic 503.

So I would handle the flag first. If HF clears it and the Space still cannot start, then it makes sense to return to normal Docker/build/runtime debugging.

A practical decision tree 
A more specific reason / detector / rule is visible
|
+--> Include that exact signal in the HF support request
     and investigate that component first.

Only "Flagged as abusive" is visible
|
+--> Ask HF to review the exact reason.
     |
     +-- HF says false positive
     |   +--> Review / unflagging is the relevant path.
     |
     +-- HF identifies a specific feature or behavior
     |   +--> Change or separate that component.
     |
     +-- Flag is cleared, but the Space still fails
         +--> Return to ordinary build/runtime debugging.

I would avoid deleting random files or repeatedly redeploying similar copies before knowing the reason, because that provides little diagnostic information.

Also, I would not read the Content Policy as saying that any application with proxy/relay functionality is automatically prohibited. The policy specifically mentions proxies/tunnels in the context of using them to bypass platform restrictions. The exact reason for this Space’s flag still needs HF-side confirmation.

If HF does identify one particular relay/networking component as the problem, that still would not necessarily mean abandoning the whole Telegram/Stremio project; separating only that component onto a more suitable host may be an option.