Snowflake Monitoring: Credit Consumption, Query Performance, and Warehouse Sizing

Snowflake’s credit based billing model makes monitoring essential for cost control and performance optimization. Without visibility into warehouse usage patterns, teams often discover that their monitoring bill has tripled alongside a traffic spike, or that a single poorly sized warehouse has been running continuously for weeks processing queries that could have completed faster on a larger cluster. According to the CNCF Annual Survey 2023, 68% of organizations cite cost management as their primary cloud native challenge, and Snowflake’s unique architecture where compute scales independently from storage creates monitoring blind spots that affect both spending and application latency.

This guide covers how to monitor Snowflake credit consumption, optimize query performance across virtual warehouses, and right size warehouses using the metrics Snowflake exposes through its ACCOUNT_USAGE schema and query history views. It includes cost scenarios for teams at different scales, best practices for warehouse configuration, and tooling options including native Snowflake monitoring, third party platforms, and infrastructure monitoring systems that correlate Snowflake telemetry with application traces.

What Is Snowflake Monitoring

Snowflake monitoring is the practice of tracking credit consumption, query execution metrics, warehouse utilization, and storage usage across Snowflake virtual warehouses to ensure queries complete efficiently, costs remain predictable, and data pipelines meet SLA requirements. Unlike traditional database monitoring where compute and storage are coupled, Snowflake decouples these layers which means you can scale compute independently but also creates complexity in understanding what drives cost.

A virtual warehouse in Snowflake is a cluster of compute resources that executes queries, loads data, and performs DML operations. Warehouses consume Snowflake credits based on their size and how long they run. An X-Small warehouse consumes 1 credit per hour. A 4X-Large warehouse consumes 128 credits per hour. Credits translate to dollars based on your contract, typically $2 to $4 per credit depending on your Snowflake edition and region.

The monitoring challenge: Snowflake warehouses auto suspend after a configurable idle period and auto resume when queries arrive. If auto suspend is misconfigured, a warehouse can run continuously consuming credits even when idle. If a warehouse is too small for the workload, queries queue or time out wasting both time and credits on incomplete work. If a warehouse is too large for simple queries, you pay for compute capacity you did not need.

Snowflake monitoring answers three core questions: Which warehouses are consuming the most credits and why? Which queries are slow, expensive, or failing? Are warehouses sized appropriately for their workload profile?

How Snowflake Monitoring Works

Snowflake exposes telemetry through views in the ACCOUNT_USAGE schema, which sits inside the SNOWFLAKE database that every Snowflake account has by default. These views surface metrics on query execution, warehouse activity, data storage, and user behavior. ACCOUNT_USAGE views lag 45 minutes to 3 hours behind real time, which is acceptable for cost analysis and performance trending but not sufficient for real time alerting on query failures or warehouse overruns.

For real time monitoring, Snowflake provides the INFORMATION_SCHEMA views which have no latency but only retain data for the current session or recent activity. Most teams use ACCOUNT_USAGE for historical analysis and cost attribution, and INFORMATION_SCHEMA or query result caching for operational dashboards.

The QUERY_HISTORY view is the primary source for query performance metrics. It logs every query executed in your account including execution time, bytes scanned, bytes written, warehouse used, and error messages if the query failed. This view lets you identify which queries consume the most credits, which queries are slow, and which workloads would benefit from a different warehouse size.

The WAREHOUSE_METERING_HISTORY view tracks credit consumption per warehouse per hour. It shows exactly how many credits each warehouse used in a given time window, which is the foundation for cost attribution and chargeback models if you run a multi tenant or multi team Snowflake environment.

The DATABASE_STORAGE_USAGE_HISTORY view tracks storage consumption over time. Snowflake charges separately for storage, typically $23 to $40 per TB per month depending on your cloud provider and region. Storage costs are usually far smaller than compute costs for active workloads, but they compound if you retain large volumes of data indefinitely without lifecycle policies.

Monitoring Snowflake at scale requires querying these views regularly, aggregating metrics by warehouse, user, query type, and time window, and alerting when thresholds are breached. Teams typically build dashboards in Snowsight (Snowflake’s native UI), export telemetry to external observability platforms, or use BI tools like Tableau or Power BI to visualize cost trends.

Monitoring Snowflake Credit Consumption

Credit consumption is determined by warehouse size and run time. A Medium warehouse (4 credits per hour) running for 30 minutes consumes 2 credits. If that warehouse auto suspends after 5 minutes of idle time, you pay for 5 minutes. If auto suspend is disabled or set too high, you pay for hours of idle time.

The most common credit consumption mistake: running a Large or X-Large warehouse with auto suspend set to 10 minutes for ad hoc queries that complete in seconds. The warehouse stays active for 10 minutes after each query, consuming credits even though no work is being done. A 10 minute auto suspend on an X-Large warehouse (16 credits per hour) costs 2.67 credits per idle period. If 20 users run ad hoc queries throughout the day, those idle periods compound into hundreds of wasted credits per month.

How to monitor credit consumption by warehouse

Query the WAREHOUSE_METERING_HISTORY view to see credit usage per warehouse per hour:

SELECT
  WAREHOUSE_NAME,
  DATE_TRUNC('day', START_TIME) AS DAY,
  SUM(CREDITS_USED) AS TOTAL_CREDITS
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY WAREHOUSE_NAME, DAY
ORDER BY TOTAL_CREDITS DESC;

This query returns daily credit totals per warehouse for the past 30 days. If one warehouse dominates credit usage, investigate its queries to determine whether it is appropriately sized or whether workload separation would reduce cost.

Identifying idle warehouse time

Warehouses that stay active without executing queries waste credits. Query WAREHOUSE_METERING_HISTORY alongside QUERY_HISTORY to find gaps where a warehouse consumed credits but ran no queries:

SELECT
  WM.WAREHOUSE_NAME,
  WM.START_TIME,
  WM.END_TIME,
  WM.CREDITS_USED,
  COUNT(QH.QUERY_ID) AS QUERIES_EXECUTED
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY WM
LEFT JOIN SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY QH
  ON WM.WAREHOUSE_NAME = QH.WAREHOUSE_NAME
  AND QH.START_TIME BETWEEN WM.START_TIME AND WM.END_TIME
WHERE WM.START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY WM.WAREHOUSE_NAME, WM.START_TIME, WM.END_TIME, WM.CREDITS_USED
HAVING COUNT(QH.QUERY_ID) = 0
ORDER BY WM.CREDITS_USED DESC;

Any rows returned represent time windows where the warehouse was active but no queries ran. This is wasted spend. The fix: reduce auto suspend timeout or enable query result caching to avoid redundant warehouse startups.

Cost scenario: 50 node data warehouse with mixed workloads

Assume a Medium warehouse (4 credits/hour, $3 per credit) running 12 hours per day for ETL jobs, and a Large warehouse (8 credits/hour) running 4 hours per day for analyst queries. Monthly credit consumption:

• Medium warehouse: 4 credits/hour × 12 hours/day × 30 days = 1,440 credits = $4,320
• Large warehouse: 8 credits/hour × 4 hours/day × 30 days = 960 credits = $2,880
• Total monthly compute cost: $7,200

If the Medium warehouse auto suspend is misconfigured and runs 24 hours per day instead of 12, monthly cost doubles to $8,640 for that warehouse alone. A single configuration error adds $4,320 per month.

Monitoring Snowflake Query Performance

Query performance in Snowflake depends on warehouse size, data volume scanned, query complexity, and whether the query can leverage result caching or partition pruning. Slow queries waste credits and delay downstream workloads. Failed queries waste credits without producing results.

The QUERY_HISTORY view surfaces three metrics that matter most for performance: EXECUTION_TIME (how long the query took to complete), BYTES_SCANNED (how much data the query read), and BYTES_WRITTEN (how much data the query wrote). High execution time on small data volumes suggests an inefficient query. High bytes scanned suggests missing partition pruning or a full table scan where a filter could have reduced scope.

Identifying slow queries

Query QUERY_HISTORY to find the longest running queries in the past 7 days:

SELECT
  QUERY_ID,
  USER_NAME,
  WAREHOUSE_NAME,
  QUERY_TEXT,
  EXECUTION_TIME / 1000 AS EXECUTION_SECONDS,
  BYTES_SCANNED / (1024*1024*1024) AS GB_SCANNED
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND EXECUTION_STATUS = 'SUCCESS'
ORDER BY EXECUTION_TIME DESC
LIMIT 20;

Any query taking more than 60 seconds should be reviewed. Check whether it is scanning unnecessary data, missing an index, or running on a warehouse too small for the workload.

Identifying queries that scan excessive data

High bytes scanned without corresponding results often indicates a query that could benefit from partition pruning or clustering keys:

SELECT
  QUERY_ID,
  USER_NAME,
  WAREHOUSE_NAME,
  BYTES_SCANNED / (1024*1024*1024) AS GB_SCANNED,
  BYTES_WRITTEN / (1024*1024) AS MB_WRITTEN,
  EXECUTION_TIME / 1000 AS EXECUTION_SECONDS
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND BYTES_SCANNED > 1000000000
ORDER BY BYTES_SCANNED DESC
LIMIT 20;

If a query scans 100 GB but writes only 10 MB, it is reading far more data than it needs. The fix: add filters, define clustering keys, or restructure the table to align with query patterns.

Query queueing and concurrency limits

Snowflake warehouses have a maximum concurrency limit that varies by size. An X-Small warehouse can run up to 8 queries concurrently. A 4X-Large warehouse can run up to 128 queries concurrently. If more queries arrive than the warehouse can handle, they queue. Queueing delays results and wastes time.

Query QUERY_HISTORY to find queries that spent time in queue:

SELECT
  QUERY_ID,
  USER_NAME,
  WAREHOUSE_NAME,
  QUEUED_OVERLOAD_TIME / 1000 AS QUEUE_SECONDS,
  EXECUTION_TIME / 1000 AS EXECUTION_SECONDS
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND QUEUED_OVERLOAD_TIME > 0
ORDER BY QUEUED_OVERLOAD_TIME DESC
LIMIT 20;

If queries consistently queue, either the warehouse is undersized for peak load or workload separation is needed. Running ETL jobs and analyst queries on the same warehouse creates contention. Use dedicated warehouses per workload type to avoid queueing.

Warehouse Sizing and Right-Sizing Strategies

Snowflake warehouses come in 10 sizes from X-Small (1 credit per hour) to 6X-Large (512 credits per hour). Larger warehouses have more compute nodes, which improves performance for parallelizable queries but does not help queries that cannot parallelize such as single row lookups or sequential scans.

The sizing decision depends on workload type. ETL jobs that scan large tables benefit from larger warehouses because they parallelize across nodes. Ad hoc analyst queries that return small result sets often complete just as fast on a Small warehouse as on a Large warehouse, so using a Large warehouse wastes credits.

When to use a larger warehouse

Larger warehouses improve performance for queries that scan large data volumes, perform complex joins, or aggregate millions of rows. A query that scans 500 GB on a Medium warehouse might take 10 minutes. The same query on an X-Large warehouse might take 2 minutes. If the query runs 100 times per day, the time savings justify the higher credit cost.

Calculate the cost per query at different warehouse sizes to determine the optimal size:

• Medium warehouse (4 credits/hour, $3 per credit): 10 minutes = 0.67 credits = $2 per query
• X-Large warehouse (16 credits/hour): 2 minutes = 0.53 credits = $1.60 per query

The larger warehouse is both faster and cheaper per query for this workload. This is the core insight: right sizing is not always choosing the smallest warehouse. It is choosing the warehouse that minimizes total cost per query while meeting latency requirements.

When to use a smaller warehouse

Ad hoc queries, dashboards that query pre-aggregated tables, and single row lookups do not benefit from large warehouses. An X-Small or Small warehouse (1 to 2 credits per hour) is sufficient for these workloads. Using a Large warehouse for a query that completes in 3 seconds wastes credits because the warehouse idles for the remainder of the auto suspend window.

Separate workloads by warehouse to avoid over provisioning. Create a Small warehouse for dashboards, a Medium warehouse for analyst queries, and a Large or X-Large warehouse for ETL jobs. This lets each workload run at its optimal size without interference.

Auto suspend and auto resume configuration

Auto suspend controls how long a warehouse stays active after the last query completes. Set this too high and you pay for idle time. Set this too low and you pay startup latency every time a new query arrives.

Recommended settings:

• ETL warehouses: 5 minute auto suspend (ETL jobs run in batches, so frequent startups are rare)
• Analyst query warehouses: 1 minute auto suspend (queries are ad hoc, so minimizing idle time matters more than startup latency)
• Dashboard warehouses: 10 second auto suspend if query result caching is enabled (dashboards reuse cached results, so the warehouse rarely needs to restart)

Startup latency for a warehouse is 5 to 15 seconds depending on size. If your queries take 30 seconds or longer, startup latency is negligible. If your queries take 2 seconds, startup latency dominates total response time. Use query result caching to avoid restarting warehouses for repeated queries.

Multi-cluster warehouses for unpredictable load

Snowflake supports multi-cluster warehouses which automatically scale from a minimum to a maximum cluster count based on query load. This prevents queueing during traffic spikes without over provisioning during low traffic periods.

A multi-cluster warehouse configured with 1 minimum cluster and 3 maximum clusters starts with 1 cluster active. If query concurrency exceeds the first cluster’s capacity, Snowflake provisions a second cluster automatically. When load decreases, the extra clusters suspend. This costs more than a single cluster but eliminates queueing and provides predictable latency during peak traffic.

Multi-cluster warehouses are best for workloads with unpredictable traffic patterns such as customer facing dashboards or API backed analytics. ETL jobs that run on a fixed schedule do not need multi-cluster scaling.

Best Practices for Snowflake Monitoring

Effective Snowflake monitoring requires combining native Snowflake telemetry with external observability platforms that correlate warehouse metrics with application traces and infrastructure signals. These practices reduce cost overruns and improve query performance across teams of every size.

Set credit consumption alerts per warehouse

Snowflake Resource Monitors let you set credit thresholds per warehouse and trigger alerts or suspend warehouses when thresholds are breached. Create a resource monitor for each production warehouse with a monthly credit limit based on expected usage. Configure the monitor to send an alert at 80% of limit and suspend the warehouse at 100% to prevent runaway spend.

A common mistake: setting a single account level resource monitor instead of per-warehouse monitors. Account level monitors do not tell you which warehouse caused the overage. Per-warehouse monitors provide immediate cost attribution and let you act before the entire budget is consumed.

Enable query result caching

Snowflake caches query results for 24 hours. If the same query runs multiple times within 24 hours and the underlying data has not changed, Snowflake returns cached results without starting a warehouse. This eliminates credit consumption for repeated queries.

Query result caching works automatically but only if the query text is identical. Adding a single space or changing capitalization invalidates the cache. Use parameterized queries or views to ensure consistent query text across users.

Use clustering keys for large tables

Tables larger than 1 TB benefit from clustering keys which organize data on disk to reduce the amount scanned during queries. A table clustered on date lets queries that filter by date skip partitions outside the filter range, reducing bytes scanned and execution time.

Clustering is not free. Snowflake reclusters tables automatically as data changes, which consumes credits. Monitor clustering depth and reclustering history to ensure clustering benefits outweigh cost. For tables that are queried frequently but updated infrequently, clustering almost always improves performance and reduces cost.

Separate production and development workloads

Running development queries on production warehouses creates cost attribution problems and risks resource contention during peak traffic. Create dedicated warehouses for development, staging, and production environments. Use lower cost warehouses (X-Small or Small) for development where query latency is less critical.

Monitor storage separately from compute

Storage cost is billed separately from compute and scales with data volume and time travel retention settings. Snowflake retains historical data for 1 to 90 days depending on your edition and configuration. Time travel enables querying past versions of tables, which is useful for auditing and recovery but increases storage cost.

Query DATABASE_STORAGE_USAGE_HISTORY to track storage growth over time and identify tables that consume the most space. Drop unused tables, reduce time travel retention for non-critical data, and archive cold data to lower cost storage tiers if your contract includes Snowflake’s archival storage option.

Tools for Monitoring Snowflake

Monitoring Snowflake at scale requires tooling that surfaces credit consumption, query performance, and warehouse utilization in real time. Native Snowflake monitoring through Snowsight provides basic visibility. External observability platforms correlate Snowflake telemetry with application traces, infrastructure metrics, and logs to give full context during incidents.

Native Snowflake monitoring with Snowsight

Snowsight includes dashboards for query history, warehouse activity, and credit consumption. These dashboards query the ACCOUNT_USAGE schema and display metrics in pre-built charts. Snowsight is sufficient for small teams that only need basic visibility and do not require integration with external observability tools.

Limitations: Snowsight does not support custom alerting thresholds, does not correlate Snowflake metrics with application traces, and does not export telemetry to third party platforms. For teams running distributed systems where Snowflake is one component among many, Snowsight alone is insufficient.

Third party observability platforms

Platforms like Datadog, New Relic, and Dynatrace ingest Snowflake telemetry via integrations that query ACCOUNT_USAGE views and forward metrics to their systems. These platforms correlate Snowflake query latency with application request traces, surface anomalies using machine learning, and provide unified dashboards across all monitored services.

Cost: Datadog charges $15 to $31 per host per month for infrastructure monitoring plus $0.10 per GB ingested for logs. Monitoring Snowflake alongside application infrastructure typically adds $1,000 to $5,000 per month depending on data volume. New Relic charges per-user fees starting at $99 per user per month, which compounds as teams grow. Dynatrace charges per-host and per-feature, with enterprise contracts starting at $10,000 per year.

CubeAPM for unified Snowflake and application observability

CubeAPM provides full stack observability for teams running Snowflake alongside microservices, Kubernetes, and cloud infrastructure. It correlates Snowflake query metrics with distributed traces, logs, and infrastructure signals in a single platform that runs inside your VPC or on premises.

CubeAPM connects to Snowflake via OpenTelemetry or direct integration with ACCOUNT_USAGE views. It surfaces query execution time, bytes scanned, credit consumption, and warehouse utilization alongside application request traces so you can see exactly which application queries are driving Snowflake cost.

Pricing: CubeAPM charges $0.15 per GB ingested with unlimited retention and no per-host or per-user fees. For a team ingesting 30 TB per month of telemetry data including Snowflake metrics, logs, and traces, monthly cost is $4,500. This is 60% to 75% lower than equivalent coverage on Datadog or New Relic.

Deployment: CubeAPM runs inside your cloud VPC or data center which eliminates public cloud egress fees (typically $0.10 per GB) and ensures compliance with data residency requirements. Snowflake telemetry never leaves your infrastructure.

CubeAPM is best for teams that need unified observability across Snowflake, Kubernetes, and application services without the unpredictable billing of SaaS platforms. It is compatible with existing Prometheus, Datadog, and OpenTelemetry agents so migration requires no agent replacement.

Open source monitoring with Grafana and Prometheus

Teams already running Grafana can query Snowflake ACCOUNT_USAGE views using the Snowflake data source plugin and visualize metrics in custom dashboards. This approach works but requires maintaining the data pipeline, defining alert rules manually, and correlating Snowflake metrics with other telemetry sources.

Grafana is free and flexible but creates operational overhead. Teams using Grafana for Snowflake monitoring typically spend 10 to 20 hours per month maintaining dashboards, updating queries, and troubleshooting data freshness issues caused by ACCOUNT_USAGE latency.

This estimate models a production ready Snowflake monitoring setup with real time alerting and multi warehouse visibility. A simpler setup using only Snowsight may cost significantly less.

Frequently Asked Questions

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.