My Space has been stuck at “Starting” all day. Logs show app running perfectly on 0.0.0.0:7860 but health checker never responds. Space: RomanaQureshi/Hayat-AI-Hajj-Medical- Emergency-Guidance Started happening today June 20 2026. Direct URL works but Space page shows Starting. Tried factory rebuild multiple times. Please help urgently — this is linked in my CV and job applications!
Hmm… I’d put this in the same neighborhood as this stale-runtime thread: not exactly proven identical, but it similarly doesn’t look like the usual app-side startup failure. The app seems alive, but the Space status / health layer stays stuck.
Thank you for your reply! That thread does
look similar to my situation. My logs show
the app running correctly on 0.0.0.0:7860
but the Space status stays stuck at Starting.
Is there anything I can do from my end,
or does this need the HuggingFace team
to intervene?
I have already tried factory rebuild
multiple times with no change.
does this need the HuggingFace team
to intervene?
Probably this one. If the issue is on the HF side, there’s probably nothing we can do until HF fixes it or notices the problem and fixes it on their own… 
@hysts ?
Same issue here. my Space has been stuck at “Starting” all day on June 20. Container logs show the app running correctly on 0.0.0.0:7860, model loads successfully, and the direct .hf.space URL works fine. But the Space page stays at “Starting” indefinitely. Factory rebuild multiple times with no change. This seems to be the same health checker issue rather than an app-side problem. @hyst, is this a known platform issue today?
Thanks for reporting this. I’ll check internally.
Thank you!
Thank you @hysts! Really appreciate you
looking into this.
Just to confirm my Space details:
Username: RomanaQureshi
Space: Hayat-AI-Hajj-Medical-Emergency-Guidance
The direct .hf.space URL works fine but
the Space page has been showing “Starting”
since this morning. I have also submitted
a support ticket (#37918).
Looking forward to hearing from you! 
Unsure related to this or not, but for now, new cases:
I’m facing this in my space: System Threat Forecaster - a Hugging Face Space by rishitpant
It’s stuck at starting. I have tried a small commit to rebuild it, and also tried factory rebuild multiple times.
Having this issue too, any suggestions on how to resolve it?
I don’t think it’s a model-loading/blocking-startup issue though — for example, I already isolated that variable: I created a brand-new minimal Space with zero custom code, no model, nothing beyond the official Gradio “Hello World” template:
python
import gradio as gr
def saludo(nombre):
return f"Hola, {nombre}!"
demo = gr.Interface(fn=saludo, inputs="text", outputs="text")
if __name__ == "__main__":
demo.launch(server_name="0.0.0.0", server_port=7860)
That Space reaches Running on local URL: http://0.0.0.0:7860 within seconds (no slow downloads, no global-scope blocking code), and it still got stuck on “Starting” indefinitely — tested with both gradio 6.6.0 and 6.19.0, same result.
Since even a zero-dependency template with instant startup shows the exact same symptom as my real app, I don’t think lazy loading would change anything here.
Anyone reported this issue ?
Already tried factory reset, restarting the space and one readMe update commit, but still it is not starting !!
Facing the same issue. Tried commits, binding the address and port (if in case it was that issue), and factory rebuild, all to no avail.
Unless you want the exact same space link, you can duplicate your space. That works fine.
Thanks. But I need exact same link as I have distributed it in cv, LinkedIn everywhere.
same problem for me…
Same for me. Also since this was first time for me deploying R shiny app on HF I thought maybe my setup is wrong. I tried deploying the default/example R Shiny Docker from image Spaces and that wouldn’t even build. It seems it has drifted from the current setup.
Yes same I am also using huggingface for first time and I am still unsure if there is an architecture mistake on my side like model being too heavy as i am on free plan but logs are showing running on http://0.0.0.0:7860 and then a series of ValueError: Invalid file descriptor: -1
Exception ignored in: <function BaseEventLoop._del_ at 0x7f0bdf426980>
Traceback (most recent call last):
File “/usr/local/lib/python3.12/asyncio/base_events.py”, line 732, in _del_
self.close()
File “/usr/local/lib/python3.12/asyncio/unix_events.py”, line 68, in close
super().close()
File “/usr/local/lib/python3.12/asyncio/selector_events.py”, line 104, in close
self._close_self_pipe()
File “/usr/local/lib/python3.12/asyncio/selector_events.py”, line 111, in _close_self_pipe
self._remove_reader(self._ssock.fileno())
File “/usr/local/lib/python3.12/asyncio/selector_events.py”, line 298, in _remove_reader
key = self._selector.get_key(fd)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.12/selectors.py”, line 190, in get_key
return mapping[fileobj]
~~~~~~~^^^^^^^^^
File “/usr/local/lib/python3.12/selectors.py”, line 71, in _getitem_
fd = self._selector._fileobj_lookup(fileobj)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.12/selectors.py”, line 225, in _fileobj_lookup
return _fileobj_to_fd(fileobj)
^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.12/selectors.py”, line 42, in _fileobj_to_fd
raise ValueError(“Invalid file descriptor: {}”.format(fd))
ValueError: Invalid file descriptor: -1 Can anyone who is experienced tell me if my issue is also platform side or it is from my side?