Bounded window of 'Scheduling failure: unable to schedule' on Streamlit Spaces, Nov 2025 - May 2026

[ashishsinha1602]

A bounded window of elevated Scheduling failure: unable to schedule on Streamlit Spaces, which I originally misfiled with Streamlit before checking the error strings. Refiling here since the scheduler is yours.

The window

From a complete census of the public Spaces catalogue (1,458,692 Spaces, runtime.stage), RUNTIME_ERROR share of Streamlit Spaces by creation month:

Created	n	RUNTIME_ERROR
2025-09	1,905	14.3%
2025-10	1,570	11.5%
2025-11	1,791	30.9%
2026-01	2,128	45.3%
2026-02	2,003	48.8%
2026-04	3,797	40.4%
2026-06	2,787	8.6%

Opens Oct→Nov 2025, peaks Jan–Feb 2026, back to baseline by June.

It is scheduling, not application failure

runtime.errorMessage sampled inside and outside the window:

Error class	2026-01/02 (n=300)	2025-09/10 (n=295)
Scheduling failure: unable to schedule	90.0%	42.0%
Launch timed out (30 min)	6.3%	18.6%
App-level crash	2.7%	27.5%

Odds ratio 12.4. Re-run independently on a fresh sample (seed differs, n=60/group): 80.0% vs 28.3%.

Decomposed against the census, non-scheduling runtime errors are flat across the whole window — 7.6% of the 2025-09/10 cohort, 4.7% at the peak, 7.1% after. The entire rise and the entire recovery is the scheduling class.

Two supporting observations

It looks like wake failure, not start failure. (RUNTIME_ERROR + SLEEPING) / n holds at 88–92% for every Streamlit month from 2025-06 to 2026-06, while RUNTIME_ERROR's share of that pair swings 12.6% → 53.1% → 9.7%. Spaces that would have been asleep are failing when woken. gcTimeout is 172800 for 100% of both samples, so it isn't a sleep-policy change.

It is oddly SDK-specific. Same months, same platform: 42.3% of the Streamlit cohort hit scheduling failures against 3.6% of Gradio and 10.9% of Docker. A scheduler problem shouldn't care about the SDK, which suggests the correlation runs through which accounts build Streamlit Spaces rather than through Streamlit itself.

I have an untested hypothesis for that and am flagging it as untested: Streamlit skews heavily toward classroom use — 26 of 300 sampled affected READMEs share a single project title, and affected Spaces are 78.7% never-modified-after-day-one against 63.3% for healthy ones. If scheduling failures concentrate in free-tier or newly created accounts, that would produce an SDK correlation with no SDK cause. I can't test account tier from outside.

Caveats

Single snapshot (2026-08-28) bucketed by creation date, so the falling tail is confounded — June–August 2026 Spaces are weeks old and may not have failed yet. The rise is not an age artifact: the 2025-06 to 2025-10 cohorts are older and fail at 8.6–14.3% against 40–49%, which runs against the age trend present in every other SDK.

Because most of these Spaces are never modified after day one, breakage-by-last_modified reproduces breakage-by-created_at almost exactly (2026-02: 50.3% vs 48.8%), so I can't separate creation cohort from last-wake cohort.

Happy to share the affected Space IDs. Related: #2743 (the general Spaces census), and streamlit/streamlit#16770 where I first misfiled this.

Data (1.46M rows): https://huggingface.co/datasets/Ashsinha1/hf-spaces-census
Method: https://github.com/ashishsinha1602/dataset-integrity-audit

[ashishsinha1602]

Follow-up with a live measurement that may help triage this, since the report above rests on error strings the API surfaces.

I re-queried 250 randomly sampled Spaces sitting in BUILD_ERROR against the public API. All 250 returned an errorMessage, but 180 of them (72%) contain no error — only Docker layer cache-miss lines and a trailing JSON stats blob. Zero of those 180 contained a traceback, an ERROR: line, a "No matching distribution" message, or any other recoverable cause.

A representative one, in full:

cache miss: [base 6/7] RUN pip install --no-cache-dir gradio[oauth]==4.44.0 "uvicorn>=0.14.0" ...
cache miss: [base 5/7] RUN --mount=target=/tmp/requirements.txt,source=requirements.txt pip install ...
{"total":25,"completed":18,"user_total":14,"user_cached":4,"user_completed":7,"miss":9,"client_duration_ms":17590}

/api/spaces/{id}/logs/build returns 401, so real logs are owner-only. From outside, the Hub reports 101,373 Spaces in BUILD_ERROR with no attributable reason — which is the underlying reason reports like this one are hard to substantiate, including mine.

Two corrections to my own reading, since both were wrong and someone else might repeat them:

• I first took the cache-miss lines as evidence of a platform build bug. They are ordinary build-log noise and do not indicate a fault.
• I then tried to infer the failing layer from the deepest cache-miss step. Those lines are not in execution order, so that inference does not hold either.

The point that survives is narrower, and is about diagnosability rather than a broken builder: for roughly seven in ten build failures, the public API's errorMessage field carries no error.

Method and code: https://github.com/ashishsinha1602/dataset-integrity-audit