BigQuery FinOps Query Pack

Which jobs spent the longest waiting to start?

Queue time by job — the symptom of undersized capacity.

Free to run — INFORMATION_SCHEMA scans no billable bytesChecked 4 Aug 2026

JOBS and TABLE_STORAGE are region-scoped.

-- Time between job creation and execution start is queue time.
SELECT
  job_id,
  user_email,
  reservation_id,
  creation_time,
  TIMESTAMP_DIFF(start_time, creation_time, SECOND)          AS queue_seconds,
  TIMESTAMP_DIFF(end_time, start_time, SECOND)               AS runtime_seconds,
  ROUND(total_slot_ms / 1000, 1)                             AS slot_seconds,
  SUBSTR(REGEXP_REPLACE(query, r'\s+', ' '), 0, 200)         AS query_preview
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
  AND TIMESTAMP_DIFF(start_time, creation_time, SECOND) > 5
ORDER BY queue_seconds DESC
LIMIT 50;

What it returns

queue_seconds
Seconds between submission and execution starting.

How to read it

  • A few seconds of queue time is normal scheduling overhead. Minutes mean contention.
  • If queueing clusters at the same hour every day, the fix is scheduling, not capacity — move the batch job off the analysts' peak.
  • Queue time on an on-demand project is invisible on your bill and very visible to the person waiting. It is the strongest non-financial argument for reservations.

Run this once, or have it run every day.

Finitizer evaluates this class of question continuously against your live BigQuery estate, tracks how each number moves between runs, and turns findings into assigned tasks. Read-only and keyless.