What goes in a BigQuery monitoring dashboard in Metabase?

A BigQuery monitoring dashboard tracks job volume, execution time, bytes scanned versus billed, slot utilization, and spend by project — and names the queries responsible. Metabase connects to BigQuery natively, so every card is plain SQL over INFORMATION_SCHEMA.JOBS — no exporter or agent in between.

What does a BigQuery monitoring dashboard look like?

Here’s the layout this guide builds. Warehouse-level numbers and the month’s spend sit at the top; query volume, performance, errors, and cache behaviour fill the middle; the bottom section follows the money — bytes, slots, and the specific queries that dominate the bill.

Which cards belong on a BigQuery monitoring dashboard?

Eight cards, updated from the classic list: percentiles instead of averages for execution time, and bytes billed — the number that costs money — beside bytes scanned.

• Jobs — volume per hour, plus queries in flight right now (area + number)
• Query execution time — p50 and p95 by day (line)
• Bytes scanned vs. bytes billed per day (bar)
• Slot utilization against the reservation (line)
• Bytes billed by project, month to date (row)
• Cache hit rate by day (line)
• Failed jobs by error type — rate limits, invalid queries, timeouts (stacked bar)
• Top queries by bytes billed, with estimated cost (table)

What data does the dashboard need?

• INFORMATION_SCHEMA.JOBS_BY_PROJECT (or JOBS_BY_ORGANIZATION) — job state, timings, total_bytes_processed, total_bytes_billed, cache_hit, total_slot_ms, error_result, user, and query text.
• A nightly rollup table snapshotting the view — both for history beyond ~180 days and so dashboard refreshes don’t re-scan the raw view.
• RESERVATION capacity (from the reservations views or config) for the slot-utilization goal line.
• Optional billing export via Google Cloud billing to reconcile estimated cost against the invoice.

How do you build it?

1. Connect BigQuery to Metabase with a service account that can read the region-qualified INFORMATION_SCHEMA views.
2. Schedule a nightly query that appends yesterday’s jobs to a rollup table — always filtered on creation_time, the column the views are partitioned by.
3. Model the rollup once (est. cost = TB billed × your on-demand rate) and point every card at the model, so cost math never varies by chart.
4. Build the bytes and top-queries cards first — they pay for the dashboard — then performance, errors, and slots.
5. Add filters for project, user, and date range, and pin the top-queries table where the data team will actually see it.

Example card SQL

SELECT
DATE(creation_time)                                   AS day,
COUNT(*)                                              AS jobs,
COUNTIF(state = 'RUNNING')                            AS in_flight,
APPROX_QUANTILES(
  TIMESTAMP_DIFF(end_time, start_time, SECOND), 100
)[OFFSET(95)]                                         AS execution_p95_s,
ROUND(SUM(total_bytes_processed) / POW(1024, 4), 2)   AS tb_scanned,
ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2)      AS tb_billed,
ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 6.25, 0) AS est_cost_usd,
ROUND(100 * COUNTIF(cache_hit) / COUNT(*), 1)         AS cache_hit_pct
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
AND job_type = 'QUERY'
GROUP BY 1
ORDER BY 1;

Related

Metrics

Integrations

Dashboards

FAQ