Estimate what a query costs before you run it
This recipe tells you what already happened. The analyzer takes a query you have not run yet and estimates what it will scan, in your browser.
Which jobs spent the longest waiting to start?
Queue time by job, the symptom of undersized capacity.
Reads metadata only, a fraction of a cent to run (10 MB minimum)Reviewed against Google’s docs, 23 Oct 2026
Permissions. Needs bigquery.jobs.listAll on the project for JOBS (BigQuery Resource Viewer has it); bigquery.jobs.create to run any query (BigQuery Job User has it).
Pick the region your data is in: every INFORMATION_SCHEMA view here is qualified by region.
-- 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.
See how Finitizer works