We’ve been experiencing Batch API degradation since March 4, 2026. The issue started with abnormally slow processing and has escalated to batches making zero progress.
Timeline:
March 4, 12:43 UTC — Batch batch_69a828e39a4081908428434be28a1df6 (60 requests) completed successfully. Last known good batch.
March 4, 13:45 UTC — Batch batch_69a83760285c81909fb8f58a466b4309 (102 requests) started processing noticeably slower than usual. Only completed 50/102 requests before expiring after the 24-hour window. No errors reported — just ran out of time.
March 5, 14:15 UTC — Resubmitted as batch batch_69a98fe7451c81908a36e4f41e902944 (102 requests). Sat at 0/102 with no progress. Manually cancelled.
March 5, 19:25 UTC — Resubmitted again as batch batch_69a9d8b5a29881909e073eef0d4f68b5 (60 requests, smaller payload). Currently stuck at 0/60 completed, 0 failed. No errors, no progress.
Pattern:
Started as slow processing (March 4), now escalated to zero progress (March 5)
No error messages returned on any batch — they either silently expire or sit indefinitely at 0
Smaller batches (60 requests) completed fine on March 4 but are now also stuck
Using /v1/responses endpoint with structured output
Environment:
Endpoint: /v1/responses
Request sizes: 60–102 requests per batch
JSONL format validated, same format that completed successfully on March 3–4
Is anyone else seeing similar degradation since March 4? Is there a known issue with batch queue processing?
I have the same issue happening on my end with no progress in batch API with gpt-5-mini.
But gpt 4.1 mini is working, may be you may consider that model.
Yeah, that pattern definitely looks concerning. Going from slow processing to zero progress without errors isn’t ideal.
I checked on our side and there aren’t any reported outages with the Batch API right now. I also ran a small test batch using the same /v1/responses flow, and it completed successfully without errors. So it doesn’t look like a system-wide failure at the moment.
A couple things that would help narrow this down:
Which model are you using for these batches?
Are the stuck batches still showing in_progress, or are they in another state?
Has your most recent resubmission made any progress since posting?
If it continues to sit at 0 with no movement, this may need a deeper look with internal logs. In that case, I’d recommend reaching out to support@openai.com and including the batch IDs you shared here so the team can investigate directly.
Let us know what model you’re running and whether anything’s changed on the latest batch.
@OpenAI_Support Also having batch processing issues. I’ve been stuck in_progress for around 6 hours. Just noticed this morning and hadn’t ran any jobs since last week. Using gpt-5-mini-2025-08-07 with around 300 jobs. Have canceled and restarted many times.
@OpenAI_Support Could you please provide any updates on this issue? We are still encountering the same problem. Processing a very small batch file (around 150KB) is taking more than two hours, and in some cases even longer.
Thanks for looking into this. Here are the details:
Model: gpt-5-mini-2025-08-07
Endpoint: /v1/responses with structured output (Zod schemas)
Current state of the latest batch:
batch_69a9d8b5a29881909e073eef0d4f68b5 — still in_progress, now at 50/60 completed (was stuck at 0/60 for hours after submission at 19:25 UTC yesterday). So it is moving, but extremely slowly.
Context — we have solid prior experience with this exact setup:
On March 3, we ran a full pipeline with the same model, same endpoint, same JSONL format, same request sizes — everything completed successfully and quickly:
All of these finished within reasonable time frames. No issues whatsoever.
Then starting March 4, same payload, same setup — degradation:
batch_69a828e39a4081908428434be28a1df6 — 60 requests → completed (this was the header phase, still fine)
batch_69a83760285c81909fb8f58a466b4309 — 102 requests → expired (only 50/102 completed before 24h timeout — processing was noticeably slower than March 3 when the identical 102-request batch completed fine)
batch_69a98fe7451c81908a36e4f41e902944 — 102 requests → sat at 0/102 with no progress, manually cancelled
batch_69a9d8b5a29881909e073eef0d4f68b5 — 60 requests → currently in_progress, 50/60 after ~12+ hours (on March 3, a 60-request batch completed much faster)
Summary: Nothing changed on our side between March 3 and March 4 — same model, same endpoint, same JSONL format, same structured output schemas, same request sizes. The only difference is processing speed on your end. March 3 was fast and reliable, March 4 onward has been slow to stuck.
Thanks for the advice. I think I should try if the problems continue. But I am a bit concerned about the quality of results I will receive. I have prerry precise task with structured output.
I can also confirm this issue with my batches. I also use gpt5-mini, and on March 4 it almost stopped working. Before that day, my batches were processed in 5-10 minutes. One of my overdue batches: batch_69a95f5ba3188190b12055b007c34cbe
I am having similar issues. I started a batch of 1709 running around 7am ET last night. It sat at completed=0 until about 4am ET, then completed 1439, and has been slowly creeping up to 1688 (current progress) since then. I’ve been using the batch API for months and have never had a run go this long.
I also just started another batch of 58, and that has been at completed=0 for about half an hour, whereas usually I could expect this batch to finish in 15 minutes or less.
@OpenAI_Support, can we get someone to look into this on OpenAI’s side?
First batch: batch_69aa1efbcf4881909c550bcaa1af12f6
Second batch: batch_69ab1c9cc96c81908ea34e740f87e924
I’m having the same issues, the difference is that I’m using gpt 5 nano for this batch api. Even cancelling the batch takes some time (it hasn’t even finished cancelling at the moment). Any ideas?
Second this, batch gpt-5-nano is being unusable, it renders 1000 rows in 12 hrs, and I need to process millions, this so slow I could do it manually. On the other hand standard service runs within api limits, no problem to get 500 jobs done per minute, so considering the price it’s still acceptable. But batch looks like being intentionally slowed down, every 2nd job stops at 99x/1000 for hours but keeps 24h completion window so nobody can officially complain.
Hey everyone, Issue is not reproducing in current testing: a /v1/responses batch progressed and completed normally.
There have also been backend improvements in this area from engineering. If anyone is still seeing batches stuck at 0 progress or expiring after partial completion, please share a recent batch ID and/or x-request-id so we can trace that specific execution path and investigate further.
(only 50/102 completed before 24h timeout — processing was noticeably slower than March 3 when the identical 102-request batch completed fine)