Persistent 503 on gemini-3.7-flash with Priority tier (Tier 2 paid) — 0% success over multiple retries

[Pau_Marin]

Hi team,

I’m hitting sustained 503 UNAVAILABLE errors on the Gemini Developer API in production. Priority tier is enabled, billing is Tier 2 (paid), and RPM/TPM quotas are not being exceeded. The model never accepts the request — failures happen at HTTP level before any streamed response.

Environment

• API: Gemini Developer API (AI Studio API key, not Vertex)
• Endpoint: POST https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:streamGenerateContent?alt=sse
• Model: gemini-3.7-flash
• Billing: Tier 2 paid project (billing account linked, paid usage history)
• Service tier: service_tier: "priority" on GenerateContentConfig
• SDK: google-genai (Python), streaming via generate_content_stream
• Caller region: EU / Spain.

Workload

• ~50k input tokens
• 12 images (multimodal)
• JSON output + thinking
• Single synchronous job per user (not batch, not massive parallel fan-out from our side)

Error

Every attempt returns immediately at HTTP layer with:

{
  "error": {
    "code": 503,
    "message": "This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.",
    "status": "UNAVAILABLE"
  }
}

Wrapped as: google.genai.errors.ServerError: 503 UNAVAILABLE

We never receive response body / stream chunks, so we cannot read x-gemini-service-tier to confirm which tier actually served the request.

Retry policy (already implemented)

Exponential backoff on 503-only:

• Up to 8 attempts (initial + 7 retries)
• Delays: 5s → 10s → 20s → 40s → 60s → 60s → 60s
• Total wait ~4–5 minutes per job before giving up

1. Is gemini-3.7-flash currently capacity-constrained globally, or region/account-scoped?
2. Does Priority tier apply to streamGenerateContent on Developer API, or only certain endpoints?
3. Is there a recommended path for production workloads that need reliability on 3.7 Flash (Vertex Provisioned Throughput, Batch, different model pool)?
4. Any ETA or status page entry for elevated 503 rates on this model?

Cannot ship reliably on gemini-3.7-flash at current capacity.

Thank you very much!

[AlphaFold_3]

I worked around the issue by implementing a fallback model free tier. If Gemini 3.7 Flash continues to return 503 errors after multiple retries, the request automatically switches to another model. This allowed the workflow to complete successfully.

Implementation:

gemini.py

Example successful run:
https//github.com/xin-chao/nguyen-oi/actions/runs/33052310408/job/98450560117#step:4:23

[Pau_Marin]

Thanks man!

But the only model that works well and make my project in the sweet spot is 3.7 so i cant downgrade the model, thats my problem.

[Shawn_Ch_ng]

Looks like the same issue with my project.

While it’s running smoothly yesterday morning but evening onwards keep showing 503 error.

No choice but keep trying on other hour.

Hopefully it works.

[Matheus_Moreira]

yes, same here, unfortunately

[smadmin]

Same here. What is going on?

[Alessio_Chianetta]

Aside from the 503 error, when it actually works, it’s much slower than it was a few days ago! Who else is having problems, or am I imagining it?

[Pau_Marin]

Feels like google is out of capacity. Giving free subscriptions to students or priority llms to their own projects…

[Mustan_lokhand]

HI @All

I have DM’ed you for project Ids

[Raushan46]

I am also getting a lot of 503 error. I am using this api to generate Quizzes.

[Toru_Yasutake]

I am seeing the same issue with gemini-3.7-flash, and I ran a long retry test to see how long it would take before a request eventually succeeded.

My workload is a receipt-processing application written in Python using the google-genai SDK. It uploads a PDF containing multiple Japanese receipts and asks Gemini to extract structured JSON data. The request uses structured output / a response schema, thinking, and max_output_tokens=65536.

Normally, when gemini-3.7-flash returns HTTP 503 twice, my application falls back to gemini-3.6-flash. The 3.6 model usually processes the same workload successfully and relatively quickly.

For this test, however, I disabled the fallback completely and kept retrying only gemini-3.7-flash after every HTTP 503.

Here are the results:

• Model: gemini-3.7-flash
• API: Gemini Developer API
• SDK: google-genai for Python
• Input: PDF containing multiple Japanese receipts
• Output: structured JSON
• Retry delay after each 503: 30 seconds
• Attempts 1 through 16: HTTP 503
• Attempt 17: SUCCESS
• Time from the start of the test to the first successful response: 1 hour 9 minutes 21 seconds
• Successful request usage:
  • Input tokens: 10,242
  • Output tokens: 3,493
  • Thinking tokens: 3,003

Interestingly, the time it took for each 503 response to come back varied significantly. Some failed requests returned in around a minute, while others took several minutes before returning HTTP 503. Therefore, the 30-second retry delay was only a small part of the total elapsed time; much of the time was spent waiting for the API request itself to return.

Immediately after the first pass finally succeeded, my application started an independent second verification pass using the same PDF and gemini-3.7-flash. The first attempt of the second pass returned HTTP 503 again within about 9 seconds.

This suggests that, at least in my case, gemini-3.7-flash is not completely unavailable. A request can eventually succeed, but capacity appears to be highly inconsistent for this relatively heavy multimodal / structured-output workload.

The notable point is that gemini-3.6-flash generally handles the same workload much more readily, while gemini-3.7-flash can remain unavailable for a very long period.

Has anyone else observed this pattern — many consecutive 503 responses over an hour or more, followed by a successful 3.7 Flash request, and then 503 again immediately afterward?

It would also be very helpful if Google could clarify whether these long waits before a 503 response indicate that the request is waiting for model capacity internally, or whether something else is happening before the 503 is returned. It would also be very helpful if Google could clarify whether these long waits before a 503 response indicate that the request is waiting for model capacity internally…

[Toru_Yasutake]

Update to my previous report:

I continued the same retry test after my previous post, without changing the model, retry interval, or fallback behavior.

The second verification pass eventually succeeded, but only after an extremely long series of HTTP 503 responses:

• Model: gemini-3.7-flash
• Same Gemini Developer API / google-genai Python SDK
• Same PDF and structured JSON workload
• Retry interval after each HTTP 503: 30 seconds
• Attempts 1–973: HTTP 503
• Attempt 974: SUCCESS
• Total elapsed time: 12 hours 22 minutes 50 seconds
• Successful request usage:
  • Input tokens: 10,254
  • Output tokens: 3,481
  • Thinking tokens: 2,845

All of the failed requests returned the same error:

503 UNAVAILABLE: This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.

There was also an interesting change in behavior during the test. For much of the long failure period, many 503 responses came back only a few seconds after the request was sent. Earlier in the test, some requests had taken several minutes before returning 503.

After attempt 974 finally succeeded, the application immediately continued with another receipt PDF containing 15 receipts.

For that next PDF:

• First verification pass: 27 consecutive HTTP 503 responses, then success on attempt 28 after 40 minutes 56 seconds
• Second verification pass: 1 HTTP 503 response, then success on attempt 2 after only 46 seconds

So within a relatively short period, I observed all three of the following behaviors with the same model and essentially the same workload:

1. More than 12 hours / 973 consecutive 503s before success
2. About 41 minutes before success
3. 46 seconds before success

This seems to indicate that gemini-3.7-flash is not completely unavailable, but that available capacity can vary extremely sharply over time.

The workload itself does not appear to explain the difference: the later PDF was slightly larger, yet it succeeded much more quickly.

I am continuing to use gemini-3.6-flash as a fallback in normal production use, because waiting for 3.7 Flash to recover is not practical.

I hope these measurements are useful for diagnosing the current 503/capacity issue. If Google needs my Project ID or any additional request details for investigation, I can provide them privately by DM.

[AITester]

I’m having like 99% 503 code fail rate, the service is unavaiable all day long, for over a week now. I need to switch models and even those models fail from time to time as well.

[Shawn_Ch_ng]

Yup, same here. around 6pm onwards (Malaysia time), keep prompt 503 & 504 error, 0% processed. Anyway, will continue trying tomorrow.

[daniel_lublinsky]

Hey, i believe that this is the issue:

Gemini 503 for Prepay clients! - HELP

Overview Contiki’s AI service is built on top of Gemini, clients setup a google account and using googles AI studio generate a API key linked to their billing. We dont want to handle billing a client usage so a key per client linked directly to their card give them direct control and monitoring of usage. Whats failing More then half of the AI clients keys dont work when we use their key. the request to the model is hung and after a minute a 503 service unavailable is thrown and absolutely no …

@Pau_Marin can you confirm you use Prepay?

[Pau_Marin]

Hello Daniel, im not in prepay.

[daniel_lublinsky]

wow ok, this ruins all of my case
i spoke to a few google people and the told me that this is a possible case and that this is not a radical assumption and google had issues with prepay in other services

when did you create your account? and do you use the default gemini cloud?

[Pau_Marin]

My account is from 2019 i think, and yes im using cloud. To be honest i just think Google is out of capacity…

[daniel_lublinsky]

@Pau_Marin
No, well maybe they do have some issue
but i have 30 keys running without issue 24 7
and the only time the has a 503 was a few months ago for a few hours

we have another 15 keys that just dont work, they get the 503 on every request
these crashes can last weeks until they finally start working
and when these crashes return exactly these 15 stop working

and after alot of investigation i come to a realization its the prepay
google billing is know to be a mess and these keys dont work with flash models
the flash lite and the pro models work
its either so rate limiting for prepay or a genuine bug

[Pau_Marin]

Oh okey, then seems like a Big. Thank you