Sustained Outage (14h+): gemini-3.5-flash generateContent hangs indefinitely on structured-output + thinkingConfig (Returns 0 bytes)

Gemini API
, ,
1

Sustained Outage (14h+): gemini-3.5-flash generateContent hangs indefinitely on structured-output + thinkingConfig (Returns 0 bytes)

Environment & Endpoint

  • Model: models/gemini-3.5-flash
  • Endpoint: generativelanguage.googleapis.com/v1beta (API-key auth)

The Issue

Since approximately 2026-07-15 08:00 UTC, we have been experiencing a complete, sustained unavailability of the gemini-3.5-flash model, characterized by two distinct and highly reproducible failure modes[cite: 1].

The most critical behavior is that requests utilizing structured output with thinking enabled are held open indefinitely with zero response bytes returned (rather than failing fast)[cite: 1].

Detailed Timeline & Observed Behaviors (All times in UTC)

  • 2026-07-15 00:25–01:42 (Healthy Baseline)[cite: 1]
    • Multiple calls with our full configuration (systemInstruction + safetySettings + responseMimeType: application/json + responseJsonSchema + thinkingConfig {includeThoughts: false, thinkingLevel: "low"}) succeeded normally (HTTP 200) with a response time of ~10.3s[cite: 1].
  • 2026-07-15 ~08:00 (Degradation Begins)[cite: 1]
    • Calls started failing with 5xx errors[cite: 1].
  • 2026-07-15 14:17, 21:25, 21:31 (The Indefinite Hang / 0-Byte bug)[cite: 1]
    • Full-configuration POST requests (with structured output and thinking enabled) were successfully accepted at the TCP/TLS layer (connect ≈ 0.04s), but remained completely hung with 0 bytes returned until client-side timeout at 60s+[cite: 1].
  • 2026-07-15 21:40 (Control Tests & Fast 503 Load Shedding)[cite: 1]
    • Control Test A: GET / → Fast HTTP 404 in < 1s (routing is healthy)[cite: 1].
    • Control Test B: POST models/gemini-2.5-flash → Fast HTTP 404 in 0.95s (“no longer available to new users”, authentication and error paths are healthy)[cite: 1].
    • Control Test C: POST models/gemini-3.5-flash (minimal text prompt, no configuration) → Fast HTTP 503 “This model is currently experiencing high demand…” in 0.82s[cite: 1].

Key Takeaways / Defects to Address

  1. Defect in Overload Handling: While a prompt 503 under heavy load (observed on minimal requests) is expected behavior, the indefinite hang (0-byte transfer) for structured-output requests with thinkingConfig indicates a serious issue where connections are kept open instead of being correctly rejected or timed out by the load-balancer/API gateway[cite: 1].
  2. Dashboard Visibility: No incidents are currently visible on the public status dashboards for the Developer API[cite: 1].

Questions for DevRel / Google Engineers

  1. Is there an ongoing, unannounced capacity issue with gemini-3.5-flash[cite: 1]?
  2. Is the infinite-hang/0-byte behavior for structured outputs + thinkingConfig a known, tracked bug[cite: 1]?
  3. Is there an estimated time of stabilization (ETA), or a recommended alternative stable model for API-key users (given that 2.5-flash returns 404)[cite: 1]?

We have raw client logs and the exact (non-confidential) request JSON payload ready to provide if requested.

2

yes, i see it as sustained 429 resource exhaustion on all 3.5-flash calls.

3

Confirmed here for the past roughly 48 hours. There seems to be a disconnect because our paid vertex AI account has had elevated 429s and 503s for the past 48 hours but the status page is all green.

4

Thanks for the input, Ilya and fcl_ops. It clearly seems like a broader systemic issue rather than an isolated incident, given that it’s affecting multiple users over the past 48 hours. The disconnect between our actual error rates and the official status page is particularly concerning. Let’s hope we get an official update here shortly.

5

Thanks for confirming — the fact that you’re seeing this on a paid Vertex AI account is significant: it means the issue spans both the Gemini Developer API and Vertex AI, i.e. the model backend itself, not any single API surface or tier. Our timeline starts ~2026-07-15 08:00 UTC (3 days now), yours ~48h — so it may still be spreading. If you have a Cloud support entitlement, opening a case and referencing this thread would help get eyes on the status-page discrepancy. Could you also share your region and whether minimal (non-structured-output) requests fail too?