Since yesterday, June 4
our service using bigquery randomly get a lot of timeout error.
the service has a cron job to run MERGE and DELETE sql to bigquery table, the sql utilize js udf not sure if it is related.
we using bigquery on demand.
same requests that can complete within 10s now hang and failing because hitting the 10 mins timeout i configured.
i am quite sure our query workload should be similar as the days before this problem.
u can see the slot estimator has a sudden spike since yesterday.
i think those hanging query just occupied all the slots.
i tried to get the timeout sql from job history,
reexecute it manually in google bigquery console,
some time it hang, and sometime it completed within 10s.
anyone else facing similar issue?
Since 2026-06-04, BigQuery on-demand queries in asia-southeast1 show severe regression for my MERGE jobs
By comparing June 3 and 4 for my table_1 and table_2, the workload did not increase, it decreased because it was interrupted by the timeout error:
table_1 processed data decreased from 3388 GiB to 2219 GiB
table_2 processed data decreased from 1173 GiB to 682 GiB
But slot efficiency degraded heavily:
table_1 slot-min/GiB increased from 2.49 to 10.60
table_2 slot-min/GiB increased from 1.35 to 24.95
p95 elapsed reached 631–1225 seconds, causing production app timeout at 10 minutes.
Manual reruns of the same SQL sometimes complete quickly and sometimes hang.
Queries use JavaScript UDF and MERGE into BigQuery tables.
BigQuery On-Demand is broken.
i switch to use reserved slots, then all timeout error gone.
i just use reserve 100 slots, it can handle my workload perfectly while On-Demand struggle with a lot timeout error.
We’re seeing the same class of issue in the US region starting June 9, 2026, with a slightly different failure signature that may help narrow down the root cause.
Our on-demand pipeline runs scheduled dbt builds. On June 9 we had 7 jobs time out across two windows (12:14 UTC and 18:14–18:34 UTC). These queries complete in 4–8 seconds under normal conditions (verified against 139–160 successful runs each in the prior 30 days).
The failures had the same pattern: Each job executed normally through 92–97% of its query plan stages, then one or more final Coalesce or Output stages received 0 slot-ms for the remainder of the 300-second timeout. The BQ scheduler dispatched slots to earlier stages without issue, then stopped entirely at the final stage. Slot concurrency at time of failure ranged from 0.3 to 90.2, which I think is within on-demand limits.
This points to stage-level slot starvation in the BQ scheduler rather than a general slowdown, which may be a different manifestation of the same underlying platform issue you’re describing.
Like you, we’ve confirmed it’s not a query regression — the queries themselves are unchanged and complete instantly when slots are available. We don’t have a reserved slots workaround available to us, so we’re hoping for a platform-level explanation or fix.
Has anyone received any response from Google on this?
We have a serious BQ on demand degradation for our SQL pipelines. It started around July 15th and has been ongoing since. There were definitely queries that could have been written better, but again - they never showed any issues earlier and we were happy to pay for resources. Now, I went back to reading execution graphs, optimizing queries, solving fan-out issues like it’s year 2000 and I’m back to working with Spark.
I have no idea what has happened, but we did not just grow tremendously or rewrote our jobs. The things that were just running are now failing. And I’m talking about simple linear executions, where the graph is just input, sort and output handling mere 2M rows.
Always the same pattern applies - the job starts, get decent start with 200 or so slots and gets bashed into “life-maintenance” mode where it gets maximum 6 slots. Nothing heavy is happening in parallel, a lot of other small jobs just run and finish up. Even if it’s a single running job, it does not get more slots - once it’s punished, it’s just turtles.
EU region, on demand slots. Something has changed on BQ side, but not finding any proof.
Random BigQuery request timeouts usually point to query complexity or resource limits rather than a system-wide issue. It can happen due to large datasets, inefficient queries, slot contention, or temporary backend load. Optimizing queries (using partitions, filters, and limiting scanned data) and monitoring execution time can help reduce these timeouts.
I subscribed to the Google Cloud Standard Support service and opened a case regarding this issue.
In our case, the issue appeared to be related to UDFs.
Google Cloud Support and Engineering investigated the intermittent UDF latency and applied a backend fix. The issue has now been resolved for our project.
