Table metadata
Last-modified timestamps and row counts from INFORMATION_SCHEMA for the specific tables you choose to monitor. This is how we know whether data arrived today.
Redwood City
- Protected this month$1.4M+62%
- Checks run154,280+41%
- Quiet failures247+19%
- Median notice41 sec−38%
New York, NY
Live monitors347
Security & data access
We read metadata. Never your data.
Connecting a monitoring tool to your warehouse is a real decision, so here is the whole picture in plain language: what Vectornosis reads, what it stores, what it can never see, and how to shut it off.
The short version
Your rows never leave your warehouse.
Freshness monitoring only needs to know when a table last changed, not what is in it. Cost monitoring only needs to know how many bytes a job billed. Neither requires reading a single row, so we do not ask for the permission to. Vectornosis is independent — not Datadog-owned — and exports OpenLineage so your metadata stays portable.
What we read
Query job statistics
Bytes billed and job durations from your BigQuery job history. This is how we detect cost spikes against your rolling baseline.
dbt run artifacts
The run_results.json file you upload. It contains model names, test names, statuses, and timings — not query results.
What we never touch
- ✕Row-level data from any table
- ✕Column values, samples, or previews
- ✕Query result sets
- ✕Anything from projects or datasets you have not explicitly added
- ✕Anything at all without a service account you created and can revoke
What we store on our side
- Table identifiers
- Project, dataset, and table names you chose to monitor
- Freshness history
- Timestamps and healthy / warning / critical status over time
- dbt results
- Model and test names with pass or fail status and duration
- Cost aggregates
- Daily bytes billed and estimated spend, not query text
- Alert recipients
- The email addresses you want notified
- Credentials
- Your service account key, encrypted at rest (AES-256-GCM)
Least-privilege access
You create a Google Cloud service account and grant it the narrowest roles that make monitoring work — metadata read access on the datasets you pick, and permission to list job history. You do not grant data viewer access, and we do not ask for it.
Because you created the service account, you control it. Deleting the key in Google Cloud revokes our access immediately and completely, without going through us or waiting on a support ticket.
- →roles/bigquery.metadataViewer — read table/dataset metadata in monitored projects
- →roles/bigquery.jobUser — list job history for cost signals (optional, recommended)
- →Dataset-level: bigquery.tables.get, bigquery.tables.list on chosen datasets only
Handling and retention
- ✓All traffic is encrypted in transit over TLS
- ✓Service account credentials encrypted at rest (AES-256-GCM via workspace vault)
- ✓Monitoring history is scoped to your workspace only
- ✓Ask us to delete your workspace and we remove your data and credentials
- · Freshness history: 90 days default (configurable per plan)
- · dbt run metadata: 180 days
- · Incident timeline: life of workspace + 1 year after close
- · Service account credentials: deleted within 30 days of workspace deletion
- · Audit log (when live): 365 days, exportable on request
Day 1 flip switches (anchor client)
When your workspace goes live, these environment flags turn on real backends without a redeploy. Demo mode stays the default until you flip them in staging or production.
WORKSPACE_DATA_MODE=live
Board + hero read Supabase workspace, not demo seed
BQ_CONNECTOR_LIVE=true
Real INFORMATION_SCHEMA freshness poll via your service account
DBT_WEBHOOKS_LIVE=true
dbt Cloud run ingest with HMAC-verified webhooks
ALERTS_EMAIL_LIVE=true
Resend delivery to configured alert recipients
ASK_VECTOR_LIVE=true
LLM grounded on workspace metadata with table-name guardrails
Staging validation: see setup docs · smoke check GET /api/v1/flip-smoke?deep=1
SOC 2 readiness (in progress)
We are not SOC 2 certified yet. This checklist tracks policies and controls we are building toward a Type I audit after the anchor client flip.
Access control policy
Draft — RBAC + SSO UI shipped; SCIM WIRE LATER
Encryption at rest
Shipped — AES-256-GCM for credentials vault
Audit logging
Partial — Settings audit panel; Supabase table WIRE LATER
Incident response runbook
Shipped — anchor walkthrough + P0 flip runbook
Vendor / sub-processor list
Published — Trust Center + DPA placeholder
Data retention enforcement
Documented — automated purge job WIRE LATER
Change management
Git + Vercel preview deploys; formal policy draft
Background checks
Founder team — expand on first enterprise hire
What we do not claim yet
Vectornosis is early and founder-built. We are not SOC 2 certified yet — that audit is on the roadmap. If your procurement process requires a completed SOC 2 report today, we are not the right fit yet, and we would rather tell you now than waste your quarter.
What we can offer instead is a narrow permission model you can audit yourself in an afternoon, and a founder who will answer security questions directly.