How scans work
What a SlashPeak BigQuery scan reads, how often it runs, what it costs, and why findings appear after the scan finishes.
A scan is a read-only pass over metadata in the projects you selected. It does not query table contents.
What a scan reads
- Job history from
INFORMATION_SCHEMA(query text hashes, bytes billed, slots, referenced tables, labels, dbt comments when present) - Table and dataset metadata (DDL, partitioning, clustering, labels)
- Storage sizes and storage billing model
- Reservation, assignment, and capacity-commitment lists (when the Reservation API and IAM allow it)
- Optional: lineage links, Knowledge Catalog entries, audit log entries, Resource Manager tags
How often scans run
SlashPeak scans active connections on a schedule. The schedule depends on your plan:
| Plan | Automatic scans | Job history per scan |
|---|---|---|
| 30-day trial | Every 6 hours | 30 days |
| Starter | Every 6 hours | 30 days |
| Growth | Every 3 hours | 30 days |
| Pro | Every hour | 60 days |
| Enterprise | Every hour, or your pick: 1, 2, 3, 4, 6, 12 or 24 hours | 90 days |
- History is how far back each scan reads BigQuery jobs. Dashboard and Usage charts go back the same number of days.
- A new connection gets its first scan from the setup wizard, or from the next scheduler run. After that, only the free trial has a Run scan button, limited to one manual scan per rolling 24 hours. Paid plans scan on their schedule.
- The schedule also sets the anomaly block size. See Anomalies.
- After a trial or plan ends, scans stop until a plan is chosen. See 30-day trial.
The first scan after connect fills Dashboard, Usage and Findings. Later scans read only the jobs since the last scan (with a short overlap, so late-arriving jobs are not missed), and refresh catalog snapshots. Some slow-changing snapshots (table storage, column lists, replicas, BI Engine capacity) are refreshed at most once a day, so scans in between reuse them.
Each scan first finds the BigQuery regions of your projects, then scans each region. If a scan fails, it is retried with a growing delay, up to 5 attempts, and resumes from the last query it saved. After the 5th failure it stays failed until the next scheduled scan.
How long data is kept
- Job history and metric rollups are kept for your plan's history window plus about one month, in whole calendar months. Older months are removed.
- Table snapshots are kept about 120 days (4 months), then removed.
- Scan runs (the scan list itself) are kept 30 days.
- Billing-export rows are kept about 13 months.
- When a trial or plan ends, all scan data is deleted 30 days later.
What a scan costs in BigQuery
INFORMATION_SCHEMA queries bill with a per-query floor even when the result is small. Scan cost tracks how many metadata queries we run, not the size of your fact tables. The scanner identity appears as the job user.
We keep the query count tight on purpose. Extra slices are expensive for you and slow for us.
After the scan
- Catalog tables in SlashPeak update (latest snapshot per BigQuery table).
- Rules run over that snapshot plus job history.
- Findings are stored as identity plus metadata. Dollar savings are computed when you view a finding, using the latest catalog and activity, not a frozen dollar column.
- Metric rollups power Dashboard and Usage charts.
Empty or partial results
- No jobs in the window → usage charts stay near zero, storage findings can still appear.
- Reservation API disabled → reservation pages are thin; query findings still work.
- Optional IAM missing → tags, lineage, catalog, and audit stay empty without failing the whole scan.
See Troubleshooting.