We run automated public-tender document analysis on gemini-3.6-flash and have been seeing a sustained ~37% failure rate on GenerateContent for the past 30 days. Every failure is HTTP 503 UNAVAILABLE: “This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.”
Account: Google AI Studio, Paid Tier 1, billing active. Project ID: gen-lang-client-0151392688. The API key used in production belongs to this exact paid project.
Cloud Console metrics (30 days, same project, same key)
| Method | Requests | Errors |
|---|---|---|
| GenerativeService.GenerateContent | 646 | 37.46% |
| FileService.CreateFile | 750 | 0.8% |
| GenerativeService.CountTokens | 718 | 0% |
These three methods are called on the same PDFs, with the same key, frequently within the same minute. CountTokens has zero errors across the entire 30-day window. Only inference fails.
What we have ruled out by measurement
Not quota or rate limiting. Zero 429 responses in 30 days. No quota above 90%.
Not the account or project. We ran an identical request (same PDF, same model, same 40-minute window) using an API key from a different Google Cloud project. Both keys returned 6 failures out of 8 calls — identical rates.
Not our runtime. Reproduced with a raw HTTPS request from a local machine, outside our serverless environment, while production concurrently completed requests in the same minute.
Not payload size or response schema. ~600 KB inline PDF, ~34k input tokens. Failure rate is identical with and without responseSchema. The same failure occurs on a 948-token document-classification request using gemini-3.1-flash-lite.
Timing
The 503 does not arrive at connection time. Measured arrival: 2.5s, 8.2s, 10.6s, 15.3s, 22.8s, 26.8s, 34.1s, 52.8s, 78.7s. Median GenerateContent latency over 30 days is 24.4s; p99 is 3 minutes. This looks like queueing followed by rejection rather than immediate refusal at admission.
Errors appear on essentially every day of the 30-day window, with no concentration by hour of day.
Questions
- Is a ~37% UNAVAILABLE rate expected for gemini-3.6-flash on Paid Tier 1?
- Is Priority inference available to a Tier 1 Gemini Developer API project for this model? We have seen reports of
service_tier: "priority"being echoed back as"standard"— is that a documented congestion fallback? - Would Vertex AI materially improve capacity for this workload, or would Provisioned Throughput be required?
- Is there a recommended retry spacing? Our current backoff retries within ~500ms, which lands in the same congestion window and fails. Spacing retries by tens of seconds succeeds roughly 2 out of 3 times, but we have seen reports of 8 attempts spaced 5s–60s still returning 0% success.
Happy to share request IDs, timestamps, or a sample payload via DM.