ZeroGPU Space stuck in APP_STARTING after Git push — Factory reboot doesn't help A Hugging Face user reported that the ZeroGPU Gradio Space "Seb Full Avatar" remains stuck in the APP_STARTING runtime stage indefinitely after a Git push of updated code, with container logs showing only the "Application Startup at 2026-10-27 00:19:23" line and none of the application's Python startup output. The user, posting as seb2oo, said restarting the Space and a factory reboot both failed to resolve the issue on the zero-a10g hardware with a persistent bucket mounted at /data, and asked the Hugging Face team to investigate whether the runtime needs an infrastructure-side reset. The user noted the application had previously run correctly on the same ZeroGPU hardware and cited a prior discussion with nearly identical symptoms, suspecting the Hugging Face runtime, container scheduling or deployment infrastructure rather than the application itself. Hi Hugging Face team, My ZeroGPU Gradio Space was working perfectly until recently, both locally and on Hugging Face. After encountering some issues and pushing updated code via Git, the Space became stuck indefinitely in APP STARTING . Space URL: Seb Full Avatar - a Hugging Face Space by seb2oo https://huggingface.co/spaces/seb2oo/seb full avatar Current symptoms: Runtime status remains APP STARTING indefinitely. The build appears to complete, but the application never starts. Container logs only display: ===== Application Startup at 2026-10-27 00:19:23 ===== None of my Python startup logs appear, even though I have print statements at the very beginning of my application. Restarting the Space does not resolve the issue. Factory reboot also fails to resolve the issue. The application was previously running correctly on the same ZeroGPU hardware. Runtime information: SDK: Gradio Hardware: zero-a10g Runtime stage: APP STARTING Persistent bucket mounted at /data I found a previous discussion describing almost exactly the same symptoms: Since the application never reaches its first Python startup logs, I suspect an issue with the Hugging Face runtime, container scheduling, or deployment infrastructure rather than the application itself. Could someone from the Hugging Face team please investigate the runtime state of my Space and check whether it needs to be reset on the infrastructure side? Thank you very much for your help