Connecting to Snowflake
Connect your Snowflake account to OneLens for cost intelligence, warehouse optimization, query and data optimization, and AI cost governance — using a read-only service user and Snowflake's built-in u
TL;DR
What this does: Connects your Snowflake account to OneLens for four things — where spend went, whether warehouses are sized right, which workloads and tables create avoidable cost, and what your Cortex AI agents, functions, and search services are consuming.
Time required: ~20 minutes
Who you need: A user with ACCOUNTADMIN to run the setup script. ORGADMIN must be enabled once at the org level for contracted-cost data. One DevOps or data-platform engineer to run the script.
What OneLens reads: Read-only SELECT on views in Snowflake's built-in SNOWFLAKE.ACCOUNT_USAGE and SNOWFLAKE.ORGANIZATION_USAGE schemas, granted through named Snowflake database roles. Your production data, tables, and rows are never accessed.
Changed in this version. The setup script no longer uses GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE. It now grants three named Snowflake database roles instead — which is what Snowflake itself recommends — and excludes the security-related views entirely. If you onboarded with the earlier script, see Migrating from the previous grant model. Your integration keeps working either way.
What You'll Get Once Connected
The integration covers four capability areas. Each answers a different question.
Cost Intelligence — where did Snowflake spend go?
Unified Cost Explorer
Snowflake spend in one view alongside AWS, GCP, Azure, OCI, and your other providers
Contracted-Cost Reporting
Dollar cost at your negotiated rate, not just credits, via ORGANIZATION_USAGE
Compute / Storage / Serverless Split
Separates warehouse credits, storage, cloud services, and each serverless feature
Cost Allocation by Tag
Break spend down by warehouse, user, role, or query tag (team / service / env)
Anomaly Detection
Alerts on unusual credit consumption, cross-checked against Snowflake's own ANOMALIES_DAILY signals
Budget Tracking
Budgets per warehouse, team, or environment with run-rate alerts
Data Transfer Cost Visibility
Egress and cross-region transfer cost, which is easy to miss on the invoice
Warehouse Optimization — are warehouses configured and sized correctly?
Load-Based Right-Sizing
Uses actual running vs. queued load, not just credit totals, to recommend a size
Scale-Up vs. Scale-Out Diagnosis
Distinguishes queries are too slow (size up) from queries are waiting (add clusters) from capacity is idle (size down)
Concurrency Analysis
Peak vs. average concurrent load per warehouse per hour
Idle Warehouse Detection
Flags warehouses missing auto-suspend or with long suspend windows, and quantifies idle credits
Spill Detection
Flags warehouses where queries spill to local or remote storage — the clearest signal a warehouse is undersized
Queue Analysis
Separates overload queuing from provisioning queuing, which have different fixes
Resize & Suspend History
Correlates configuration changes with cost changes, so you can see whether a change worked
Query & Data Optimization — what creates unnecessary cost?
True Query-Level Cost
Credits attributed to individual queries via QUERY_ATTRIBUTION_HISTORY — see Reading Cost Numbers Correctly for what this does and doesn't include
Query-Pattern Ranking
Groups queries by parameterized hash and ranks patterns by total cost, cost per execution, and frequency
Cost Regression Detection
Week-over-week change per query pattern, so a query that quietly got 4× more expensive surfaces on its own
Pruning Efficiency
Partitions scanned vs. total, per table and per query pattern — usually the largest single lever
Cache Effectiveness
Percentage scanned from cache, to find workloads re-reading the same data
Compilation Overhead
Flags patterns where compilation, not execution, dominates runtime
Storage Optimization
Large low-activity tables, excessive Time Travel and Fail-safe overhead, rapid storage growth
Service ROI Analysis
Automatic Clustering, Search Optimization, Materialized Views, and Query Acceleration — cost of the service against measured benefit
AI Cost Governance — which models, functions, and agents consume credits?
Cortex Agent Cost
Cost, requests, credits per request, and tokens per request, per agent
Agent Tool Attribution
Traces an agent request down to the underlying Cortex Analyst and Cortex Search calls it triggered
LLM & AI Function Cost
Input, output, and total tokens by model, function, user, role, warehouse, and query tag
Token Efficiency
Tokens per request and cost per request, with anomaly and regression detection
Cortex Search Cost
Serving, embedding, and batch-query cost per search service
Cortex Analyst & Guardrails
Request volume and credit consumption, including guardrail scan cost
Fine-Tuning & Provisioned Throughput
Training-run cost and provisioned-throughput utilization
Unified AI View
Snowflake AI spend next to OpenAI, Anthropic, Bedrock, and your other AI providers
Security at a Glance
Does OneLens read our production data?
No. Access is restricted to the built-in SNOWFLAKE database via Snowflake's own ACCOUNT_USAGE and ORGANIZATION_USAGE views. The role has zero privileges on any other database.
What exactly is granted?
Three Snowflake-managed database roles — USAGE_VIEWER, GOVERNANCE_VIEWER, and OBJECT_VIEWER — plus the three ORGANIZATION_USAGE roles. SECURITY_VIEWER is deliberately not granted.
What does excluding SECURITY_VIEWER protect?
Login history, user records, role grants, sessions, network policies, secrets, and credentials stay inaccessible. None of these have a cost-management purpose.
Does the grant include more than OneLens reads?
Yes, and it's worth knowing. GOVERNANCE_VIEWER is required for QUERY_HISTORY, and it also carries ACCESS_HISTORY (which columns a query touched). OneLens does not ingest ACCESS_HISTORY. Snowflake's role granularity does not allow separating the two — see Secure-View Alternative.
Does OneLens see query text?
By default, yes — we read QUERY_TEXT so we can show you the exact query to fix. If your queries carry sensitive content, ask your OneLens contact to enable hash-only mode: we ingest QUERY_PARAMETERIZED_HASH (plus QUERY_PARAMETERIZED_HASH_VERSION) instead. The hash is one-way, so literal values can never be reconstructed.
Does query-level cost data expose query text?
No. QUERY_ATTRIBUTION_HISTORY has no QUERY_TEXT column at all — only IDs, hashes, tags, user, and credits. Cost Intelligence and the cost-ranking half of Query Optimization work unchanged in hash-only mode.
Does OneLens see user identities?
Yes — USER_NAME, ROLE_NAME, and warehouse owner appear in usage views and are used for per-user and per-team attribution.
Is access read-only?
Yes. ONELENS_ROLE has no INSERT / UPDATE / DELETE / CREATE privileges. It can run only SELECT on metadata views.
What authentication is used?
RSA key-pair. Snowflake-signed JWTs only; no shared secrets in flight.
How is data transmitted and stored?
TLS 1.2+ in transit; encrypted at rest. Private keys and credentials are stored encrypted and never logged.
Can I restrict by IP?
Yes — see the network policy step. OneLens egress IPs are 35.244.46.16/32, 34.120.137.88/32, 35.201.115.143/32.
Where does the data live?
Contact OneLens for the current Trust & Security overview — region/cloud, retention policy, sub-processors, SOC 2 / ISO 27001 status, and DPA.
Cost of the Integration
OneLens creates one XSMALL warehouse and nothing else. Querying ACCOUNT_USAGE is not itself billed — you pay only for the warehouse time spent running the queries.
Figures assume ONELENS_WH is XSMALL (1 credit/hour) with 60-second auto-suspend.
Core cost & metering queries
~5 min/day → 2.5 credits/month
$5–10/month
Deep warehouse, query, storage, and AI views
~10–20 min/day → 5–10 credits/month
$10–40/month
Storage in your account
None — OneLens writes nothing back
$0
New warehouses or objects
One XSMALL warehouse; no clusters, tasks, or tables
$0
Estimated total
7.5–12.5 credits/month at $2–4/credit
$15–50/month
Where you land depends mostly on query volume. The two heaviest reads are QUERY_HISTORY and TABLE_STORAGE_METRICS; an account running millions of queries a day will sit at the upper end. Three things keep it bounded:
Every OneLens query is time-bounded on the view's primary time column. Snowflake rejects unbounded scans of these views anyway, and unbounded scans are the main way tools like this get expensive.
Closed months are read once and never re-queried.
After the initial backfill, reads are incremental.
How It Works
Snowflake charges for compute (credits consumed by virtual warehouses and serverless features), storage (per TB), and data transfer. Bills grow when warehouses are oversized or idle, when queries scan more data than they need, when serverless services run without anyone checking their return, and — increasingly — when AI features consume tokens nobody is tracking.
Snowflake exposes all of this through metadata views in the shared SNOWFLAKE database. OneLens reads five categories: usage and metering, contracted cost, query metadata and attribution, object and storage metadata, and AI service usage.
Everything OneLens reads is a view Snowflake maintains for you. OneLens creates no tables, materializes nothing inside your account, and writes nothing back.
What OneLens Reads
All views are in SNOWFLAKE.ACCOUNT_USAGE unless marked otherwise. Latency is Snowflake's published maximum for that view.
Cost Intelligence
WAREHOUSE_METERING_HISTORY
3 hours
Credits per warehouse per hour
METERING_HISTORY
3 hours
Cloud-services credits up to 6h; Snowpipe Streaming up to 12h
METERING_DAILY_HISTORY
3 hours
Daily rollup including the cloud-services adjustment
ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY
up to 72 hours
Dollar cost at your contract rate
ORGANIZATION_USAGE.RATE_SHEET_DAILY
up to 72 hours
Your per-credit and per-TB rates
DATA_TRANSFER_HISTORY
2 hours
Egress and cross-region transfer
ANOMALIES_DAILY
3 hours
Snowflake's own anomaly signals, used to corroborate ours
Warehouse Optimization
WAREHOUSE_LOAD_HISTORY
3 hours
Running, queued-overload, queued-provisioning, and blocked load
WAREHOUSE_EVENTS_HISTORY
3 hours
Resize, suspend, resume events
QUERY_HISTORY
45 minutes
Queue times, spill bytes, compilation time, partitions scanned
Warehouse configuration (size, auto-suspend, min/max clusters, scaling policy) has no ACCOUNT_USAGE view. It comes from MONITOR USAGE ON ACCOUNT plus MONITOR ON WAREHOUSE, which is why the setup script grants both.
Query & Data Optimization
QUERY_ATTRIBUTION_HISTORY
8 hours
Credits per query; no query text. Excludes Adaptive Warehouses
QUERY_METERING_HISTORY
1 hour
Per-query credits for Adaptive Warehouses
QUERY_INSIGHTS
—
Snowflake's own detected query problems
TABLE_STORAGE_METRICS
90 minutes
Active, Time Travel, Fail-safe, and retained bytes per table
DATABASE_STORAGE_USAGE_HISTORY
3 hours
Storage growth per database
STAGE_STORAGE_USAGE_HISTORY
2 hours
Internal stage storage
TABLE_DML_HISTORY
6 hours
Write activity, to find high-storage/low-activity tables
TABLE_PRUNING_HISTORY
6 hours
Pruning efficiency per table
TABLE_QUERY_PRUNING_HISTORY
4 hours
Pruning efficiency per table per query
COLUMN_QUERY_PRUNING_HISTORY
4 hours
Column-level pruning
QUERY_ACCELERATION_ELIGIBLE
3 hours
Queries that would benefit from QAS — the ROI input
Serverless & Service Costs
SERVERLESS_TASK_HISTORY
3 hours
All
TASK_HISTORY
45 minutes
All
PIPE_USAGE_HISTORY
3 hours
All
SNOWPIPE_STREAMING_CLIENT_HISTORY
2 hours
All
AUTOMATIC_CLUSTERING_HISTORY
3 hours
All
DYNAMIC_TABLE_REFRESH_HISTORY
3 hours
All
MATERIALIZED_VIEW_REFRESH_HISTORY
3 hours
Enterprise+
SEARCH_OPTIMIZATION_HISTORY
3 hours
Enterprise+
SEARCH_OPTIMIZATION_BENEFITS
6 hours
Enterprise+
QUERY_ACCELERATION_HISTORY
3 hours
Enterprise+
Edition matters for ROI analysis. Materialized View, Search Optimization, and Query Acceleration cost-vs-benefit analysis requires Enterprise Edition or higher. On Standard Edition those views do not exist, and OneLens shows the sections as unavailable rather than empty. Everything in Cost Intelligence and Warehouse Optimization works on Standard.
AI Cost Governance
CORTEX_AGENT_USAGE_HISTORY
1 hour
Agent requests, credits, tokens, tool-level detail
SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY
1 hour
Snowflake CoWork interactions — not in the agent view
CORTEX_AI_FUNCTIONS_USAGE_HISTORY
—
AI function token and credit usage
CORTEX_AISQL_USAGE_HISTORY
—
AI functions used inside SQL queries
CORTEX_FUNCTIONS_USAGE_HISTORY
—
Legacy Cortex function usage
CORTEX_FUNCTIONS_QUERY_USAGE_HISTORY
—
Legacy per-query Cortex function usage
CORTEX_SEARCH_SERVING_USAGE_HISTORY
1 hour
Search serving cost
CORTEX_SEARCH_DAILY_USAGE_HISTORY
3 hours
Daily search + embedding cost
CORTEX_SEARCH_BATCH_QUERY_USAGE_HISTORY
1 hour
Batch query cost
CORTEX_ANALYST_USAGE_HISTORY
1 hour
Analyst request volume and credits
CORTEX_AI_GUARDRAILS_USAGE_HISTORY
—
Guardrail scans, flags, credits, tokens
CORTEX_DOCUMENT_PROCESSING_USAGE_HISTORY
1 hour
Document AI processing
CORTEX_FINE_TUNING_USAGE_HISTORY
1 hour
Fine-tuning run cost
CORTEX_PROVISIONED_THROUGHPUT_USAGE_HISTORY
—
Provisioned throughput utilization
CORTEX_REST_API_USAGE_HISTORY
—
Cortex REST API consumption
Agent cost needs two views, not one. CORTEX_AGENT_USAGE_HISTORY explicitly excludes requests that originate from Snowflake CoWork; those land in SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY. Reading only the first understates agent spend. OneLens reads both and reconciles them without double-counting. Snowflake also lists a SNOWFLAKE_COWORK_USAGE_HISTORY view — the naming is in transition, so OneLens probes for both and uses whichever is present in your account.
What OneLens Will NOT Access
Your actual data, tables, or rows in any database other than
SNOWFLAKESECURITY_VIEWERscope — no login history, user records, role grants, sessions, secrets, or credentialsACCESS_HISTORY— never ingested, even thoughGOVERNANCE_VIEWERtechnically permits itAny write access — read-only by design
Reading Cost Numbers Correctly
This section exists because the most common question on a Snowflake FinOps rollout is "why don't your per-query costs add up to my bill?" They will not, and that is correct behaviour.
Query-attributed credits are always less than warehouse credits. CREDITS_ATTRIBUTED_COMPUTE covers only credits burned executing the query. Snowflake explicitly excludes warehouse idle time, cloud services credits, storage and data transfer costs, serverless feature costs, and tokens processed by AI services.
OneLens shows the gap as an explicit idle and overhead line rather than silently spreading it across queries. If that line is large, it is itself the finding: you are paying for a warehouse to sit awake.
Some queries are missing by design. Queries at or under roughly 100 ms are too short to attribute and do not appear at all. On a high-frequency workload this is a visible number of rows, though a small share of credits.
Adaptive Warehouses use a different view. Jobs on Adaptive Warehouses do not appear in QUERY_ATTRIBUTION_HISTORY; their per-query credits come from QUERY_METERING_HISTORY. OneLens reads both and labels which source a figure came from.
Attribution starts mid-August 2024. Data before that may be incomplete regardless of your backfill window.
Concurrent queries are apportioned, not measured. When queries run at the same time, warehouse cost is split by weighted average resource consumption. An individual query's cost is a fair estimate, not a meter reading — trust the pattern-level rollups more than any single row.
Accelerated queries have two cost columns. For a query accelerated by QAS, true cost is CREDITS_ATTRIBUTED_COMPUTE plus CREDITS_USED_QUERY_ACCELERATION. OneLens sums both.
Contract cost and credits reconcile only in UTC. ACCOUNT_USAGE and ORGANIZATION_USAGE will not tie out unless the session timezone is UTC. OneLens sets this on every connection; if you reconcile by hand, run ALTER SESSION SET TIMEZONE = UTC; first.
Prerequisites
Snowflake Edition: Standard, Enterprise, Business Critical, or VPS. Free trial accounts are not supported for production integration. Service ROI analysis requires Enterprise or higher.
A user with the
ACCOUNTADMINrole to run the setup script.ORGADMINenabled on at least one account in your Snowflake org. This is a one-time, org-wide prerequisite that makesORGANIZATION_USAGEviews populate. You do not needORGADMINto run the setup script — only to flip the enablement switch in Snowsight (Admin → Accounts) on the org's primary account, if not already enabled.A machine with
opensslinstalled, to generate the key pair.
Identify Your Snowflake Account Identifier
Log into Snowsight (Snowflake's web UI).
In the bottom-left corner, click your username → Connect a tool to Snowflake.
Copy the Account Identifier. It looks like one of:
myorg-myaccount(preferred format:<org_name>-<account_name>)abc12345.us-east-1(legacy format:<account_locator>.<region>)
You'll also need your server URL, which is just <account_identifier>.snowflakecomputing.com.
Generate a Key Pair
OneLens uses key-pair authentication. Snowflake is in the middle of a phased rollout that retires password authentication for users and enforces MFA — key-pair is the recommended secure pattern for any automated integration and avoids being swept up in that deprecation.
Open onelens_rsa_key.pub and copy the key body — everything between -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----, with line breaks removed.
Run the OneLens Setup Script
This creates a dedicated read-only role, user, and warehouse, attaches your public key, and applies the grants. Run it as ACCOUNTADMIN in a Snowflake worksheet.
Paste your public key body where the script says <PASTE_PUBLIC_KEY_BODY_HERE>.
You should see "Statement executed successfully" for each command.
Verify the Setup
ONELENS_USER is a TYPE = SERVICE user, which means it cannot log into Snowsight. Verify as ACCOUNTADMIN impersonating the role, or via SnowSQL with the private key.
Note the explicit column lists — Snowflake advises against SELECT * on these views because columns are added over time.
How to read the results:
Queries 1, 3, and 5 return rows → the core integration is working.
Query 2 returns nothing →
ORGANIZATION_USAGEis not enabled, or you bought through a reseller. See troubleshooting items 1 and 9.Query 4 returns nothing → most likely the 8-hour latency, or an account on Adaptive Warehouses. Re-run tomorrow before escalating.
Query 6 returns nothing → expected if you don't use Cortex AI functions. Not an error.
Any query fails with "object does not exist or not authorized" → note which view, and check its Edition requirement before assuming a grant problem.
Connect to OneLens
In OneLens, open Settings → Connections → Snowflake and provide:
Account Identifier
From step 1 (e.g., myorg-myaccount)
Server URL
<account_identifier>.snowflakecomputing.com
Username
ONELENS_USER
Role
ONELENS_ROLE
Warehouse
ONELENS_WH
Database
SNOWFLAKE
Private Key
Full contents of onelens_rsa_key.p8, including headers and line breaks
Passphrase (only if encrypted)
The passphrase from step 2
Per-credit rate (only if reseller-purchased)
Your $/credit and $/TB rates if USAGE_IN_CURRENCY_DAILY is empty
Snowflake Edition
Standard / Enterprise / Business Critical / VPS — determines which ROI modules activate
Hash-only mode (optional)
Request here if raw query text must not leave your account
Optional: Cost Attribution by Query Tag
Snowflake's Query Tags let you attribute costs to teams, services, or environments. QUERY_TAG appears in both QUERY_HISTORY and QUERY_ATTRIBUTION_HISTORY, so tagging gives you tag-level dollar cost, not just tag-level query counts. OneLens parses JSON tags into key/value pairs automatically:
This is the highest-leverage optional step on this page. Without tags, cost allocation stops at warehouse and user. With tags, it reaches teams and services.
Data Refresh Schedule
OneLens pulls Snowflake usage, cost, and query metadata once per day. Snowflake's own view latency is the binding constraint, not our schedule:
QUERY_HISTORYup to 45 minutesMost metering and load views up to 3 hours
METERING_HISTORYcloud-services credits up to 6 hours; Snowpipe Streaming up to 12 hoursQUERY_ATTRIBUTION_HISTORYup to 8 hours — the longest of any view OneLens reads, and the reason query-level cost lags query metadata by roughly a dayUSAGE_IN_CURRENCY_DAILYup to 72 hours, and not finalized until the month closes
Polling more often would not surface fresher data, and would multiply warehouse cost.
Closed months are static once Snowflake finalizes them — pulled once and not re-queried. Current-month figures may shift until the month closes. Query-level cost for the last 24 hours may be incomplete because of the 8-hour attribution latency; treat yesterday's per-query numbers as provisional.
If you need faster refreshes for a specific use case — intra-day anomaly detection, or watching an agent rollout — contact OneLens support. Cortex views have 1-hour latency and can support a faster cadence for AI cost specifically.
Data Privacy & Security
Read-only access —
ONELENS_ROLEhas noINSERT/UPDATE/DELETE/CREATEon your data.Metadata only — access is limited to the
SNOWFLAKEsystem database; your production data, tables, and rows are never read.Named database roles, not blanket privileges — three specific roles instead of
IMPORTED PRIVILEGES.No
SECURITY_VIEWER— login history, user records, role grants, sessions, secrets, and credentials remain inaccessible.No
ACCESS_HISTORYingestion, even thoughGOVERNANCE_VIEWERpermits it.Encrypted credentials — at rest and in transit; private keys are never logged.
No mutation — OneLens cannot modify warehouse settings, drop objects, or run any non-
SELECTstatement.Network restriction supported — pin access to OneLens egress IPs.
Hash-only mode available if raw query text must never leave your account.
Troubleshooting
Appendix: Migrating from the Previous Grant Model
If you onboarded with the earlier script, you have GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE, which already covers every view on this page — the integration keeps working with no changes. You only need to act if you want the tighter grant.
Do not revoke before confirming a healthy 24-hour cycle. Revoking first will break ingest until the new grants propagate.
Appendix: Secure-View Alternative
If your security team objects to GOVERNANCE_VIEWER because it technically exposes ACCESS_HISTORY, there is a stricter pattern: create your own views in your own database that select only the columns OneLens needs, and grant ONELENS_ROLE access to those views alone. ONELENS_ROLE then receives no database roles on SNOWFLAKE at all.
The trade-off is real: you own roughly 40 view definitions and must update them as Snowflake adds columns or as OneLens adds capabilities — which is exactly the drift described in troubleshooting item 6, except now on your side. Most customers accept the database-role grant instead. If you want this pattern, contact OneLens and we'll supply the DDL for the current view set.
Appendix: Password Authentication (Not Recommended)
Key-pair is the default and supported path. If you cannot use key-pair — typically only for short-lived testing:
Snowflake is phasing out password auth for service users on a rolling timeline.
The user must be created as
TYPE = LEGACY_SERVICE(notSERVICE) to bypass MFA enforcement.Provided for completeness only; we strongly recommend against it for production.
Then share the password with OneLens instead of the private key.
Frequently Asked Questions
Need Help?
Snowflake Documentation:
Snowflake Support: https://community.snowflake.com/
OneLens Support: support@astuto.ai

