Gemini Files API: intermittent processing FAILED/code 13 and HTTP 500 on identical synthetic video
We are reporting intermittent Gemini Developer API Files failures observed in our pipeline on September 10, 2026, with the same error message continuing to be reported by other developers through September 16. The failures interrupted a video-editing pipeline before model generation. Waiting for file processing, polling status, and repeating failed uploads add substantial delay before an affected Gemini video request can produce a usable result. We have retained logs and a small synthetic reproduction.
Errors
- Uploaded videos enter
FAILED; diagnostic probes retain file error code13and messageThe file failed to be processed. - Files status requests return
500 INTERNALwithFailed to convert server response to JSON.
These are separate from output-JSON validation errors. The affected operations are video upload/processing and Files status polling.
Continued reports and time impact
This error continues to be reported. Another team reported the same Files HTTP 500 on September 10, and a new September 16 report describes repeatable file-listing failures with the same message. The latter concerns listing rather than our status-polling operation, so we cannot confirm that the underlying cause is identical. Our own controlled reproduction is dated September 10; these reports do not establish a continuous service-wide outage.
The operational impact is the total wait for a usable answer. When a video remains in processing, generation must wait for polling to report ACTIVE. A failed status request or terminal FAILED state can then add backoff, another upload, and another processing wait. Our September 10 resume records contain 15 explicit HTTP-500 retry messages and 17 re-upload messages, alongside terminal failures. Repeated polling and recovery therefore add overhead to affected video calls and can still end without a result.
We also have a separate generation-latency issue: on September 14, 12 ReadTimeout attempts each consumed 180 seconds, matching our configured client timeout. Across 10 affected logical requests, that totals 36 minutes of aggregate failed-attempt time before subsequent attempts completed; parallel execution means this is not necessarily 36 minutes of wall-clock delay. These generation timeouts are distinct from Files polling failures.
For that September 14 experiment, 13 of 261 generation attempts with a recorded response or transport error (4.98%) encountered a timeout or HTTP 503: 248 attempts returned responses, 12 timed out and one returned 503. Counting requested results rather than retries, 11 of 248 completed logical requests (4.44%) experienced at least one transport/API failure before completion. All 11 eventually succeeded. Two additional start events lack a recorded response or transport-error outcome in that day’s logs and are excluded from these percentages.
For comparison, the September 16 experiment records 0 transport/API failures across 347 generation attempts with returned responses (0% observed) through 18:52:40 local time; 123 cache hits are excluded. The workload and concurrency changed, so these are descriptive samples rather than a controlled comparison or a claim about all Gemini traffic.
We cannot calculate a reliable failure percentage for Files upload/status polling: historical logs retain errors and re-upload messages but do not retain a complete count of successful uploads and status polls. The generation percentages above must not be presented as the Files failure rate.
We do not have a reliable end-to-end average covering upload, polling, retries and generation across all Gemini calls, and are not claiming every call is slow. We need guidance on reducing the substantial waits in affected calls, rather than relying only on repeated polling and resubmission.
Controlled evidence
Three sequential uploads of identical synthetic video bytes produced the following outcomes. These times are trial starts, in UTC:
| Trial | Start, September 10, 2026 | Outcome | Elapsed before cleanup |
|---|---|---|---|
| 1 | 17:37:03.656573 | FAILED, code 13 | 3.59 s |
| 2 | 17:37:07.674474 | ACTIVE | 3.20 s |
| 3 | 17:37:11.335736 | FAILED, code 13 | 2.97 s |
The synthetic MP4 was 186,832 bytes, five seconds, H.264, 320x240, 30 fps, without audio. Each trial used a fresh upload of the same local file; status was polled every two seconds. SDK retries were disabled for this probe. No generation requests were made. Each trial’s remote test file was deleted afterward; no cleanup errors were recorded.
An earlier real-video control also both succeeded and failed across identical-byte uploads and passed a complete local FFmpeg decode. Its format was H.264/yuv420p, 854x480, 1 fps, with AAC audio. A successful local decode does not establish compatibility with every remote decoder, but intermittent failure of the independent tiny synthetic control is why we suspect a Files-service issue.
Environment: Windows, official Python google-genai SDK version 2.22.0, Gemini Developer API. A model name is not applicable to the synthetic probe because it makes no generation calls.
Reproduction procedure
- Create a short synthetic H.264 MP4 once; retain the same bytes for every trial.
- Call
client.files.upload(file=...). - Poll
client.files.get(name=...)until ACTIVE or FAILED, with a bounded deadline. - Save UTC times, state, file error code/message and any HTTP exception.
- Delete that trial’s test file and repeat with the unchanged local file.
This reproduction is intermittent and historical; continued public reports are described above. The production resume logs also contain HTTP 500 status-polling failures, but the three synthetic trials above ended in File states rather than HTTP exceptions.
Related existing report: client.files.list() raises ServerError 500: "Failed to convert server response to JSON" · Issue #815 · googleapis/python-genai · GitHub
Questions for Google
- Was there a known Files processing/status incident during these UTC times, or can you check for a project-specific backend condition?
- Can file-storage quota produce this 500/code-13 pattern, and how should we check storage when Files operations are failing?
- Is inline video the recommended alternate route? What total encoded-request limit applies to
generateContent, given the 20 MB video guidance and 100 MB general file-input guidance? - Which Google-generated diagnostic identifiers should we retain, and what private channel can we use to provide project details and identifiers?
- What processing latency and polling interval should we expect for small video files, and is there a recommended way to avoid repeated upload/poll cycles when this error persists?
- For the separate generation timeouts, do you recommend streaming, background Interactions, or a different client/server deadline for video review? We want to reduce time to a usable result without repeatedly restarting the same work.
We can provide the sanitized probe script and synthetic fixture. No API keys, authorization headers or private source footage are included in this report.