My Space (rasrahma06/rahmaras-er-predictor) has been stuck on
“Preparing Space” for over 12 hours.
Please help force-restart or investigate the Space.
There have been similar code-related issues in the past, but the cases where the process gets stuck on “Preparing” can’t be explained by the code alone. As for the issue where it gets stuck on “Preparing” indefinitely, there was a similar case in the past due to a glitch on Hugging Face.
This looks less like a normal application build failure and more like either:
The important clues are:
8501;That combination usually points away from a simple requirements.txt failure or Python traceback. If the app process has really started, but the Hub UI still stays on Preparing Space, then the remaining question is whether Hugging Face’s routing/readiness layer can actually reach the app.
Please check the YAML block at the top of your README.md.
Hugging Face Spaces are configured through README YAML:
The key distinction is whether this is a Streamlit SDK Space or a Docker Space.
If your README says something like:
sdk: streamlit
app_file: app.py
then port 8501 is expected.
Hugging Face’s Streamlit Spaces documentation says Streamlit Spaces use port 8501, and warns not to override it in .streamlit/config.toml:
So if this is sdk: streamlit, I would check:
1. Is there a .streamlit/config.toml file?
2. If yes, does it override the port?
3. If it overrides the port away from 8501, remove that override.
4. If it does not override the port, then port 8501 is probably not the issue.
Also note that Hugging Face has deprecated Streamlit as a default built-in SDK option. New Streamlit Spaces are now expected to use the Docker SDK with the Streamlit template:
That does not automatically mean your current Space is broken because of the deprecation, but it is useful context.
If your README says:
sdk: docker
then the port contract is different.
For Docker Spaces, the Spaces Configuration Reference says app_port defaults to 7860.
Streamlit normally starts on 8501, so if this is a Docker Space and Streamlit is listening on 8501, your README should explicitly include:
sdk: docker
app_port: 8501
For Docker, I would make sure all three layers agree:
README.md:
app_port: 8501
Dockerfile:
EXPOSE 8501
Startup command:
streamlit run app.py --server.port=8501 --server.address=0.0.0.0
If Docker is exposing 7860 while Streamlit is listening on 8501, the container can look “started” in the logs while the Space remains unreachable from Hugging Face’s proxy/readiness layer.
A Space staying in Preparing Space for 12+ hours is not a normal startup delay.
The Spaces config docs describe startup_duration_timeout as the maximum time a Space is allowed to start before being considered unhealthy, with a default of 30 minutes:
So if the Space is still in Preparing Space after many hours, especially after a restart, that suggests something is stuck beyond the normal app startup window.
There are several similar reports where a Space stayed stuck in Preparing, Building, or a misleading status state even though the user had already tried restart/rebuild/factory rebuild:
So I would not treat this as a completely new class of problem. It looks more like a recurrence or variant of an existing Spaces stuck-state pattern, unless the README/Docker port configuration turns out to be wrong.
Please paste or inspect the YAML block at the top of README.md.
Useful fields:
sdk: <sdk-type>
app_file: <app-file>
app_port: <app-port-if-docker>
python_version: <python-version-if-set>
startup_duration_timeout: <timeout-if-set>
Most important question:
Is this sdk: streamlit or sdk: docker?
Try the direct runtime URL, not only the Hub page:
https://<space-subdomain>.hf.space/
If the direct .hf.space URL loads but the Hub page still says Preparing Space, that strongly suggests a Hugging Face status/UI/control-plane mismatch.
If the direct .hf.space URL does not load, then the problem is more likely readiness/proxy/port/startup-related.
For Docker or custom server setups, the app should bind to:
0.0.0.0
not only:
localhost
127.0.0.1
For Streamlit Docker, the command should look like:
streamlit run app.py --server.port=8501 --server.address=0.0.0.0
Sometimes the log line saying Streamlit started is not the final story. The app may start, then crash or hang while loading a model, file, database, cache, or secret.
I would check whether the container logs show anything after the Streamlit startup line:
Out-of-memory?
Permission denied?
Missing file?
Download timeout?
Auth/token error?
Model loading hang?
Cache path issue?
Spaces should be treated as rebuildable from a clean state. If the app depends on files that were created interactively, cached in a previous container, or written to ephemeral disk, a rebuild/restart may lose them.
This can create confusing “it worked before, then got stuck after restart/rebuild” behavior.
Based on the symptoms you described, my estimate would be:
Most likely:
A Spaces-side stuck deployment/status/readiness/proxy state.
Also plausible:
Docker Space port mismatch: Streamlit listens on 8501, but app_port is missing or still 7860.
Less likely:
Normal dependency installation failure, because the build reportedly succeeds.
Less likely but still possible:
The app starts Streamlit successfully, then hangs or crashes during model/data initialization.
If the README/Docker/port settings look correct and the Space is still stuck, I would contact Hugging Face Support.
There are forum discussions where users are directed to contact:
website@huggingface.co
Example:
When contacting support, include enough information for them to inspect the stuck deployment state directly.
Useful information to include:
Space URL:
<space-url>
Account / namespace:
<account-or-org>
SDK type:
<sdk: streamlit OR sdk: docker OR other>
README YAML:
<full README YAML block>
If Docker:
<app_port value>
<Dockerfile EXPOSE line>
<startup command>
Hardware:
<CPU Basic / CPU Upgrade / GPU type / other>
Latest commit SHA:
<commit-sha>
Approximate time the issue started:
<timestamp + timezone>
Direct .hf.space URL status:
<loads / does not load / status code / screenshot>
Build log final lines:
<final 20-50 lines>
Container log excerpt:
<lines showing Streamlit started on port 8501>
<any lines after startup>
Hello Hugging Face Support,
My Space appears to be stuck on “Preparing Space” for more than 12 hours despite a successful build.
Space URL:
<space-url>
Account / namespace:
<account-or-org>
Hardware:
<hardware-plan>
Issue summary:
- The Space has been stuck on “Preparing Space” for over 12 hours.
- Build logs appear to complete successfully.
- Container logs show Streamlit starting successfully on port 8501.
- Restarting the Space does not resolve the issue.
- The Space is on a paid CPU Upgrade plan.
I have checked the likely port/configuration issue:
SDK type:
<sdk-type>
README YAML:
<readme-yaml>
If this is a Docker Space, app_port is:
<app-port-value>
If this is a Streamlit SDK Space, I understand Streamlit Spaces normally use port 8501.
Because the app process appears to start successfully in the container logs, this looks more like the Space deployment/status/readiness/proxy layer is stuck and not transitioning the Space to a usable running state.
Could you please force-restart, clear the stuck deployment state, or investigate the Spaces readiness/proxy/status state for this Space?
Additional details:
Latest commit SHA:
<commit-sha>
Approximate time the issue started:
<timestamp-timezone>
Direct .hf.space URL status:
<direct-url-status>
Build log excerpt:
<build-log-excerpt>
Container log excerpt:
<container-log-excerpt>
Thank you.
sdk: docker, verify app_port: 8501.sdk: streamlit, port 8501 is expected, but check that .streamlit/config.toml is not overriding it..hf.space URL works while the Hub UI still says Preparing, that points even more strongly to a status/control-plane mismatch.website@huggingface.co with the Space URL, logs, README YAML, SDK type, hardware, commit SHA, and direct .hf.space status is appropriate.