Batch API - Jobs Stuck in PROCESSING for 72+ Hours

Gemini API
,
1

Model: gemini-2.5-flash
Issue Type: Batch jobs not completing after 72+ hours

PROBLEM DESCRIPTION:
Seven (7) batch jobs submitted on December 29, 2025 remain in “JOB_STATE_PROCESSING”
status after 72+ hours. Expected completion time is 1-24 hours per documentation.

Job IDs:
[List your 7 job IDs here if you have them]

SYMPTOMS:

  1. Jobs submitted successfully via Batch API
  2. Files uploaded successfully (received file IDs)
  3. Jobs show as “PROCESSING” in Google AI Studio
  4. No progress or completion after 72+ hours
  5. No error messages or failure status

ATTEMPTED RESOLUTIONS:

  1. Verified API quota status (Tier 1 paid account)
  2. Checked quota dashboard - all limits show as reset
  3. Confirmed file uploads successful (38.2 MB JSONL, ~5,000 records)
  4. Verified API key permissions
  5. Attempted smaller batch submissions (100 records) - same result
  6. Rate limiting respected (2 RPM quota compliance)
  7. Attempted new submissions with proper JSONL formatting

CURRENT IMPACT:

  • Cannot complete batch processing workflow
  • New submissions also failing with “Error on line 1: No request specified”
    (despite valid JSONL format)
  • Unable to progress with 5,000+ record dataset enrichment

EXPECTED RESOLUTION:

  1. Clarification on why original 7 jobs remain in PROCESSING state after 72+ hours
  2. Either completion of existing jobs OR guidance on safely canceling/resubmitting
  3. Resolution of “No request specified” error for new submissions

TECHNICAL DETAILS:

  • Batch file format: JSONL (validated)
  • Input size: 38,283,116 bytes (~5,000 records)
  • API endpoint: gemini-2.5-flash:batchGenerateContent
  • Submission method: Official google-genai SDK (Python)
  • Account tier: Paid Tier 1
  • Rate limiting: 2 RPM (respected with 35-second delays)
3

Hi @Kevin_Johnson, welcome to the community!

Even if the JSON is valid, the schema expected by the Batch API is strict. The API parser looks for a specific top-level key (request) and fails immediately if it is missing. Batch API Input File

Please check the JSON structure in the File generation script.

These stuck jobs are likely zombie jobs. They may have failed internally without reporting the final status back to the API surface, or the specific queue for gemini-2.5-flash in your region is stalled. Please try to cancel the job and re-run. canceling-batch-job

Thank you!

5

I’m having a similar issue where everything was working fine but all of a sudden all my jobs (even when I submit something small) get stuck in processing and never go through. It’s been over 24 hours with this issue now.

6

I’m seeing the same issue. Everything was working fine until yesterday morning. Tried smaller batches and different models, but nothing helped.

8

Same here. The problem occurred 24h ago.

10

Same Here, It’s been 32 hours since the batch job was created and it is still showing JOB_STATE_PENDING

11

Hey All,

Thanks for your report. We’ve pushed a fix that should resolve the problem. Please check and let us know if the problem persists.

13

I have jobs that say JOB_STATE_PENDING. I am using Gemini 2.5-flash-lite. The following is one of batch jobs I have.

batches/0bajidhcyen83vnevhhp5d2n9kvmz44y24no

Would you please let me know if I am doing anything wrong?

14

We just updated some things on the batch service side to try and get more batches through the queue for 2.5 Flash-Lite. In general, there is a lot of demand for this model right now so it puts pressure on batch requests.

15

Thanks for your response, Logan. That means, it will eventually complete my tasks in the queue, correct?

16

@sguven asked the last question in this thread and never got an answer, so here is what I can offer — with an honest limit up front: I have no data from the period you were affected. I only started measuring Gemini batch queue times on 14 August 2026, so I cannot tell you what happened to your December jobs.

What I can give you is a yardstick for telling “slow” from “stuck”, which is really what the question was.

I run continuous probes against the batch APIs and publish the distributions. Gemini, 30-day rolling window, measured 31 Aug 2026:

model                      median    p90      spread    n
gemini-2.5-flash            130 s    286 s     2.2x     239
gemini-2.5-flash-lite        81 s    170 s     2.1x      57
gemini-3.7-flash            166 s    482 s     2.9x     501

The spread column is the useful one. On 2.5-flash the slowest tenth of jobs finish at only 2.2x the median — these are among the tightest distributions I measure anywhere (the equivalent figure on two OpenAI models is 70x and 74x).

That matters for your question, because it means a healthy 2.5-flash queue does not have a 72-hour tail. At a 2.2x spread, “slow” looks like five minutes, not three days. So a job sitting for 72 hours was almost certainly not queueing — it was stuck, which is a different failure with a different fix. Treating it as a fault rather than waiting it out was the right instinct.

The practical threshold, if it helps next time: past about five minutes on 2.5-flash you are already outside the slowest tenth I have measured. Beyond that you are not looking at queue time any more.

One bounded observation rather than a claim: in the 17 days I have been watching Gemini batch, I have recorded no Google batch outage — while logging a 15-hour one at another provider on 28 August. Seventeen days is a short window and I would not generalise from it, but it is consistent with Logan’s capacity explanation above being about a specific demand spike rather than a standing problem.

Method and the full distributions: How batchwatch measures batch API queue times | batchwatch
The Gemini model pages: Google batch API queue times, measured | batchwatch

Disclosure: batchwatch.dev is mine. This is my own probe data — contributors: 0 on these models — so treat it as one well-instrumented account’s view rather than the market’s. Happy to add any Gemini model people here want timed.