> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Google BigQuery on Vortex IQ > Monitor Google BigQuery health, cost and reliability signals, and catch incidents and runaway spend early. Monitor Google BigQuery health, cost and reliability signals, and catch incidents and runaway spend early. No changes are made without the configured approval policy. Read-only operations do not modify the connected system; schedules, access scopes, API usage and data handling remain governed by Vortex IQ controls. [Connect or manage this source](https://app.vortexiq.ai/workbench/settings/sources) · [How connecting works](/integrations/connector-catalogue) | **31** | **14** | **Build your own** | **Ready to build yours** | **7** | | ------------------- | ---------------- | ------------------ | ------------------------ | -------------- | | performance signals | automated checks | automated fixes | workflows | API operations | ## Monitor performance 31 performance signals. Signals with an alert band can raise Nerve Centre alerts; every signal supports a merchant-configured watcher. | Signal | Outcome | Alert behaviour | What it tracks | | ------------------------------------------------ | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **BigQuery Event Ingest vs Ecom Orders** | Protect revenue | Merchant rule | Fivetran / Dataflow ingest stall while orders flow = analytics blind spot; dashboards silently go stale. | | **Bytes Scanned (24h)** | Run operations | Merchant rule | SUM(total\_bytes\_processed) from INFORMATION\_SCHEMA.JOBS. BigQuery-defining - on-demand billing is per byte scanned (\~\$6.25/TiB). This IS the spend signal. | | **Bytes-Scanned Cost +50% Week-over-Week** | Run operations | Merchant rule | BigQuery-distinctive - un-pruned / runaway query scanning a giant un-partitioned table is the #1 cost surprise. | | **Bytes-Scanned Cost vs Ecom Order Volume** | Protect revenue | Merchant rule | BigQuery-distinctive XC - on-demand spend should track ecom volume (more data to analyse = more bytes). Divergence = wasted scan cost. | | **Estimated On-Demand Query Cost (24h)** | Run operations | Merchant rule | total\_bytes\_billed × on-demand rate (\$6.25/TiB default; first 1 TiB/month free). Capacity-priced projects show slot cost instead. | | **Job Error Rate %** | Control risk and change | Alert band 0.1 / 1 | Share of jobs with error\_result set in INFORMATION\_SCHEMA.JOBS (quota exceeded, permission, syntax, resources). | | **Job Error Rate Spike (>1% in 1h)** | Control risk and change | Alert band 0.1 / 1 | Alerts for Job Error Rate Spike (>1% in 1h). | | **Pending Jobs (waiting for slots)** | Run operations | Merchant rule | Jobs in PENDING state from jobs.list - sustained pending = reservation under-provisioned or concurrency cap hit. | | **Query Jobs per Hour (live)** | Run operations | Watch only | Count of QUERY jobs from INFORMATION\_SCHEMA.JOBS in the last hour. Baseline-relative, no absolute band. | | **Query Latency p95 (ms)** | Customer experience | Alert band 50 / 200 | BigQuery analytics queries measured in seconds - threshold reflects warehouse use case, not OLTP. | | **Reservation Slot Saturation (>90% sustained)** | Run operations | Alert band 70 / 90 | Alerts for Reservation Slot Saturation (>90% sustained). | | **Slot Utilisation %** | Run operations | Alert band 70 / 90 | slots/allocated ÷ reservation capacity (Cloud Monitoring). Sustained 100% on a reservation = queueing; on-demand has no slot cap to hit. BigQuery-distinctive capacity sur | | **Slow-Query Rate %** | Customer experience | Alert band 1 / 5 | Share of query jobs with duration > 5s in INFORMATION\_SCHEMA.JOBS. | | **Streaming Buffer Lag (s)** | Run operations | Alert band 1 / 10 | Streaming-insert buffer flush lag - high lag means freshly streamed rows aren't queryable yet (ingest pipeline backpressure). | | **Top 10 Most Expensive Queries** | Run operations | Watch only | Ordered by total\_bytes\_processed from INFORMATION\_SCHEMA.JOBS. The optimisation hit-list - add partitioning / clustering / pruning here. | | **Total Storage (TB)** | Grow revenue | Alert band 70 / 90 | Sum of active + long-term logical bytes across datasets (tables.get / TABLE\_STORAGE). Storage is cost-anchored - growth = bill growth. | | **BigQuery Health Score** | Run operations | Merchant rule | Description pending editorial review; the signal is live. | | **BigQuery Query Spike vs Ecom Order Rate** | Protect revenue | Merchant rule | Description pending editorial review; the signal is live. | | **Query Latency p99 (ms)** | Customer experience | Alert band 100 / 500 | Description pending editorial review; the signal is live. | | **Active Datasets** | Run operations | Watch only | Count from datasets.list. | | **Bytes Scanned by User (7d)** | Grow revenue | Watch only | GROUP BY user\_email (hashed) from INFORMATION\_SCHEMA.JOBS. Surfaces the top spenders for cost attribution. | | **Concurrent Query Jobs** | Run operations | Merchant rule | RUNNING jobs from jobs.list - interactive concurrency quota defaults \~100/project. Approaching cap = queries queue or fail. | | **Expensive Queries During Checkout Window** | Protect revenue | Merchant rule | Expensive Queries During Checkout Window, broken down by row. | | **Largest Table (GB)** | Run operations | Watch only | From INFORMATION\_SCHEMA.TABLE\_STORAGE active\_logical\_bytes. Top tables drive storage cost. | | **Last Table Snapshot Age (hours)** | Run operations | Alert band 24 / 72 | BigQuery time-travel retains 7 days by default; table snapshots / scheduled exports are the explicit backup. Reflects newest snapshot age. | | **Long-Term Storage %** | Run operations | Watch only | long\_term\_bytes ÷ (active + long\_term). Higher = more tables untouched 90d, billed at \~half rate - informational cost lever. | | **Query Cache Hit Rate %** | Customer experience | Alert band 95 / 80 | Share of jobs where cache\_hit = true in INFORMATION\_SCHEMA.JOBS - cached results are free, so a rising cache rate cuts cost. BigQuery-distinctive. | | **Query Latency p50 (ms)** | Customer experience | Watch only | Median (end\_time - start\_time) from INFORMATION\_SCHEMA.JOBS. | | **Quota-Exceeded Errors (24h)** | Control risk and change | Merchant rule | Jobs failing with quotaExceeded reason - concurrency / bytes-billed / API quota hit. BigQuery-distinctive failure mode. | | **Slot-ms Consumed (24h)** | Run operations | Watch only | SUM(total\_slot\_ms) from INFORMATION\_SCHEMA.JOBS - the capacity-pricing cost anchor (vs bytes for on-demand). | | **Top 10 Slowest Queries** | Customer experience | Watch only | Top 10 Slowest Queries, broken down by row. | ## Audit risks and opportunities A fix status appears only where the action, inputs, approval, verification and recovery controls are mapped. Candidate remediations are never executable. | Check | Severity | Outcome | Why it matters | Fix status | | ----------------------------------------------------------------- | -------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | **Connection pool saturation above 90%** | critical | Customer experience | At 90% of the connection pool in use, the database is close to refusing new connections outright. Once it does, every part of the application that needs a fresh database connection, includin | Report only | | **Disk usage above 90%** | critical | Run operations | A database that runs out of disk stops accepting writes entirely, which for most stores means orders, inventory updates and customer records stop being saved, not just that the database gets | Report only | | **Query error rate above 1% in last 5 minutes** | critical | Run operations | More than 1 in 100 queries is failing right now. Depending on what those queries do, this can mean orders not saving, pages failing to load product or customer data, or background jobs silen | Report only | | **Bytes Scanned +50% Week-over-Week** | high | Run operations | Bytes scanned jumping 50 percent week over week is the leading indicator of a runaway query or a new unpartitioned workload; costs follow within the billing cycle. | Report only | | **Job Error Rate Spike >1% in 1h** | high | Customer experience | Job errors spiking past 1 percent breaks the pipelines that dashboards and models silently depend on. | Report only | | **Last successful backup older than 72 hours** | high | Run operations | If something goes wrong with this database right now, the most recent point it can be restored to is over 3 days old. Every order, customer record and inventory change since that backup woul | Report only | | **Replication lag above 10 seconds** | high | Run operations | Anything reading from the replica, reports, dashboards, or read traffic split off the primary for capacity, is now up to 10+ seconds stale. If the primary fails while lag is this high, the r | Report only | | **Reservation Slot Utilisation >90% Sustained with Jobs Pending** | high | Run operations | Sustained reservation-slot saturation with jobs pending means workloads are queuing every day; capacity or scheduling needs a decision. | Report only | | **Slow-query rate above 5% of total** | high | Customer experience | More than 1 in 20 queries is landing in the slow bucket. That is frequent enough to be a pattern, not noise, and it means a meaningful share of every page load or job that touches this datab | Report only | | **p95 query latency above 200ms sustained 15m** | high | Customer experience | One in twenty queries against this database is taking over 200ms, sustained for at least 15 minutes, not a brief spike. Any storefront page, checkout step or order sync that depends on this | Report only | | **Buffer / cache hit rate below 80%** | medium | Run operations | More than 1 in 5 reads is missing the cache and going to disk instead, which is markedly slower. This shows up as everything the database does feeling incrementally heavier, rather than as o | Report only | | **Quota-Exceeded Errors Detected (>0 in 24h)** | medium | Customer experience | Quota-exceeded errors mean jobs are being refused outright; whatever depends on them is already stale. | Report only | | **Single Query Scanning >1 TiB (un-partitioned / un-pruned)** | medium | Run operations | A single query scanning over a tebibyte almost always means a missing partition filter; one WHERE clause can cut its cost by orders of magnitude. | Report only | | **Query Cache Hit Rate Below 50% (cost lever unused)** | low | Run operations | Cache hit rate below half means the warehouse is recomputing answers it already produced; free savings are being left off. | Report only | ### Build your own automated fixes 14 checks report findings on Google BigQuery today. Turn any finding into an automated fix with a Vortex IQ workflow: **13,885 read and write operations across 229 connectors** are available as building blocks, with approval, verification and rollback on every change. ## Automate approved work Vortex IQ is integrated with **6 read** and **1 write** operations across projectdatasettables, projectjobs, projectdatasets, projectquerys, projecttimeserys on Google BigQuery. Combine them with anything from the **13,885 operations across 229 connectors** to automate the work in your own words. Changes follow the merchant's configured approval policy: the target, proposed change, affected records, risk, reversibility and verification plan are shown before execution. Read-only operations do not modify the connected system. [Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=bigquery) | Resource | Read operations | Write operations | | -------------------- | --------------- | ---------------- | | projectdatasettables | 2 | 0 | | projectjobs | 2 | 0 | | projectdatasets | 1 | 0 | | projectquerys | 0 | 1 | | projecttimeserys | 1 | 0 | Signed-in users see the full catalogue in the workflow builder, filtered to the sources they have connected. ### Ready to build your first Google BigQuery workflow Pick a trigger, add the operations above as steps, and every step that changes data pauses for your approval. Monitoring and audits are live now and can start any workflow you build. *** *Generated from the connector capability graph. Counts reflect the servable registry after alias normalisation and de-duplication, and refresh automatically when the registry changes.*