My Docker Space (free cpu-basic) has been stuck in APP_STARTING for over an hour and won’t come up.
What I’m seeing:
The API reports stage: APP_STARTING with hardware.current: null while hardware.requested: cpu-basic. So no machine is actually being allocated.
In the Hardware settings, the “CPU basic” card shows a spinner as if it’s continuously searching for resources.
The public endpoint times out (HTTP 000).
When it did briefly start earlier, the container logs were completely clean — the app bound correctly to 0.0.0.0:7860 and logged Server listening, but the UI never transitioned to Running.
What I’ve already tried (none worked):
Restart (rebuilds in ~0.5s from cache, then straight to “starting”, nothing happens)
Factory rebuild (full rebuild completes, still stuck)
Toggling hardware / re-selecting CPU basic
This looks like a scheduling / hardware-capacity issue on HF’s side rather than my app. Is there a current capacity shortage on the free cpu-basic pool? How long does this usually take to resolve, and is there anything I can do besides waiting?
Thanks!
I have some news, my space just did runtime error
Scheduling failure: unable to schedule
Container logs:
I can confirm that I am experiencing the same issue on my side.
I tested a newly created Docker Space with a minimal Streamlit application. The image builds successfully, but the Space remains stuck at “Starting”, and the container log shows only:
===== Application Startup =====
This appears to be the same issue reported in the following threads:
Multiple users started reporting the issue during the same time period.
Both newly created and previously working Spaces are affected.
Minimal applications using different frameworks and base images reproduce the issue.
The image build completes successfully, but the Space becomes stuck during application startup.
Some affected Spaces eventually report “Scheduling failure: unable to schedule”.
In at least one report, the API shows hardware.current as null while cpu-basic remains requested.
Since the issue is reproducible with minimal applications across different users and Spaces, this looks more like a Hugging Face-side scheduling, hardware-allocation, or runtime infrastructure issue than an application-specific problem.
The public status page currently shows the service as operational, but this may be a partial issue affecting only Space startup or the free cpu-basic scheduling pool.