Community Cloud apps spin forever: Streamlit's own static JS files intermittently hang (new app, single visitor)

Community Cloud
1

Since about 23:48 UTC on Nov 3, 2026, several of my Community Cloud apps load only part of the way and then spin indefinitely. One app on the same account still works perfectly. I’ve ruled out my app code as far as I can and would appreciate someone looking at the hosting side.

Apps

Environment (current)

  • Python 3.14.10 (Cloud default; I chose 3.12 in Advanced settings but the log still shows 3.14.10)
  • streamlit==1.56.0 (Tornado), pandas==3.1.0, extra-streamlit-components==0.1.80, reportlab==5.1.0
  • Private GitHub repo; the build log is clean (dependencies install, no errors)

What happens The page stays on the spinner. Inside the app iframe (/~/+/), document.readyState stays "interactive", and several of Streamlit’s own frontend files under /~/+/static/js/ never finish downloading (for example ErrorElement.*.js, useRequiredContext.*.js, emotion-is-prop-valid.*.js). Earlier, with other versions, the result was a TypeError: Failed to fetch dynamically imported module .../~/+/static/js/TextInput.*.js on the login page, or Markdown with unsafe_allow_html=True rendering as raw text (presumably because rehype-raw didn’t load).

Evidence that it isn’t the app code

  1. The same static file alternately hangs and succeeds. From the browser on the brand-new app, fetching three of Streamlit’s own static files twice each in a row (10-second timeout):

    ErrorElement.xCwUz6pJ.js       HUNG 10013ms

    useRequiredContext.C6MAk7EW.js HUNG 10002ms

    lib.B_Qh5M3c.js 200 112ms

    ErrorElement.xCwUz6pJ.js 200 110ms

    useRequiredContext.C6MAk7EW.js 200 113ms

    lib.B_Qh5M3c.js 200 110ms

    These are static files served before any app script runs, and the app had a single visitor.

  2. /_stcore/health drops requests on the affected apps but not on the working one. curl -4 -m 8, 12–15 requests each, same network, same minute (000 = no response within 8 s):

    jewelry:  200 200 200 200 000 000 200 200 000 200 200 200 200 200 200

    skill: 200 000 200 200 200 200 200 200 200 200 200 200 200 200 200

    pest: 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200

    A static JS file on the skill app with plain curl failed 6 of 12 at the worst point. A public CDN file fetched from the same machine at the same time succeeded 8 of 8.

  3. The app runs correctly locally on the identical versions (Python 3.14, Streamlit 1.56.0): login, multipage navigation, st.dialog and the data editor all work, with no errors in the server log.

  4. A fresh deploy under a new subdomain behaves the same, so it doesn’t seem tied to old sessions or one app’s state. Reboots helped only briefly.

  5. streamlitstatus.com showed “All Systems Operational” throughout.

Possibly related library issues I hit while troubleshooting (reporting in case they’re useful):

  • Streamlit 1.58.0 with starlette 1.10.0 (what an unpinned rebuild installs): the log repeatedly shows RuntimeError: Expected ASGI message 'http.response.start', but got 'http.response.body' from starlette_static_routes → starlette_gzip_middleware.py (_MediaAwareGZipResponder.send_with_compression). On Cloud, static paths are under /~/+/static/, so _should_bypass_static_gzip doesn’t match them and they go through the gzip subclass. That subclass appears to assume pre-1.5 starlette behavior. Pinning starlette==1.4.1 removed those errors locally.
  • Streamlit 1.66.x binds the IPv6 wildcard :: by default (Uvicorn server started on :::8501). On Cloud those apps never loaded at all; the same app on 1.58 bound 0.0.0.0 and was reachable.

What I’ve tried: pinning Streamlit to 1.58.0, 1.66.0 (with server.address = "0.0.0.0") and 1.56.0; pinning starlette; rebooting; deleting and redeploying; deploying a second copy under a new subdomain; testing in incognito.

Is there a known problem with static file delivery on Community Cloud right now, or anything else I should try? Happy to provide full logs.

2

Thanks for the detailed evidence—especially the same static assets alternating between hanging and succeeding. The available documentation doesn’t confirm a current Community Cloud static-file delivery incident, so I can’t verify the hosting-side cause from these sources. Your reports are useful to include in a support case; share the affected app URLs, timestamps, complete Cloud logs, and the comparison with the app that works. The deployment troubleshooting guide covers remotely stuck apps and WebSocket/proxy checks, but it doesn’t specifically address intermittent static-asset delivery on Community Cloud.

As a limited check, review Cloud logs for resource-limit or server errors; Streamlit notes that resource issues can slow an app or make it nonfunctional, and recommends caching or reducing large data/model loads where applicable (resource-limit guidance). Rebooting clears app memory and forces a fresh build, but since it helped only briefly, that isn’t a confirmed fix (app management). Sources: Deployment troubleshooting; Resource limits; App management.

Sources: