Snowflake Cost Monitoring: Who Is Spending What, and How to Catch It Early (2026)

Snowflake cost monitoring means knowing, every day, which warehouses, services, teams and queries are using credits, and hearing about a change before it reaches the invoice. Snowflake gives you everything you need to do it: cost screens in Snowsight, usage views in the SNOWFLAKE database, tags for attribution, budgets and resource monitors for limits, and built-in anomaly detection. The catch is that each source has a different delay, scope and blind spot. This guide maps them, shows the SQL for each job, and ends with a simple daily, weekly and monthly routine. We checked every fact and figure in this guide against Snowflake’s documentation.

This article is part of our Snowflake cost optimization guide.

What is Snowflake cost management?

Snowflake cost management is the practice of seeing, attributing, limiting and reducing what you spend on Snowflake. Snowflake’s own cost management framework splits it into three parts: visibility (understand, explore and attribute cost), control (budgets, resource monitors and limits) and optimization. Monitoring is the visibility part, done continuously.

Before you monitor anything, know what you are paying for. Snowflake bills three usage types: compute, storage and data transfer. Compute splits into virtual warehouse compute, serverless compute and cloud services compute. Warehouses bill per second, with a 60-second minimum each time a warehouse starts. You pay for cloud services only when they exceed 10% of that day’s warehouse usage. AI features now bill in their own unit, covered below. On demand in AWS US East, a credit costs $2.00 on Standard, $3.00 on Enterprise and $4.00 on Business Critical. For the full price list, see our Snowflake pricing guide.

Where does Snowflake cost data live?

Snowflake cost data lives in three places: the Cost management screens in Snowsight, the ACCOUNT_USAGE schema (one account, in credits) and the ORGANIZATION_USAGE schema (all accounts, including cost in your currency). They disagree in the short term because each has a different delay, from 45 minutes to 72 hours.

The Cost management screens in Snowsight

In Snowsight, go to Admin > Cost management. The pages are Organization Overview (contract balance and spend per account), Account Overview (spend summary, spikes and savings suggestions) and Consumption (daily, weekly or monthly cost, filterable by usage type and by tag). Snowflake says cost information can take up to 72 hours to appear there. Organization Overview is not available to on-demand accounts or to contracts signed through a reseller.

The ACCOUNT_USAGE and ORGANIZATION_USAGE views

For anything the screens do not show, query the views. The ACCOUNT_USAGE schema keeps a year of history, including dropped objects. ORGANIZATION_USAGE covers every account in the organization and can be queried from the organization account or an ORGADMIN-enabled account.

Two consequences matter for monitoring. First, “today” is never complete: a number you read at 9 a.m. will grow. Second, currency figures are the slowest and can still change until the month closes, so use credits for daily monitoring and currency for monthly reporting. Customers who bought through a reseller cannot query the currency views at all. For a step-by-step tour of these screens and views, see how to check your Snowflake costs.

What should you monitor in Snowflake?

Monitor four things: compute by warehouse, serverless and cloud services credits, storage, and AI usage. Warehouses are usually the largest line, but serverless features and AI functions bill under their own service types and do not show up in warehouse views, so a warehouse-only dashboard can miss a real increase.

Start with the view Snowflake uses for billed credits. METERING_DAILY_HISTORY has one row per day and service type, and its CREDITS_BILLED column already includes the cloud services adjustment:

-- Credits billed per day and service type, last 30 days
SELECT usage_date,
       service_type,
       ROUND(SUM(credits_billed), 2) AS credits_billed
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_DAILY_HISTORY
WHERE usage_date >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY usage_date, service_type
ORDER BY usage_date DESC, credits_billed DESC;

WAREHOUSE_METERING is warehouse compute. Everything else (AUTO_CLUSTERING, SERVERLESS_TASK, PIPE, SEARCH_OPTIMIZATION, QUERY_ACCELERATION, AI_SERVICES and more) is a separate feature with its own history view. Snowflake notes that its list of service types is not complete, so expect names you do not recognize.

Compute by warehouse

WAREHOUSE_METERING_HISTORY is hourly. Its CREDITS_USED column ignores the cloud services adjustment, so it can be higher than your bill. The gap between CREDITS_USED_COMPUTE and CREDITS_ATTRIBUTED_COMPUTE_QUERIES is idle time, which is often the cheapest cost to remove.

Storage

STORAGE_USAGE gives daily bytes for tables, internal stages and Fail-safe. Snowflake says this view and DATABASE_STORAGE_USAGE_HISTORY use a different measurement from billing, so use them to compare databases and spot growth, not to reproduce the invoice.

AI

Cortex AI features bill in AI Credits, a unit separate from the platform credits that warehouses use. An AI Credit costs $2.00 with global routing and $2.20 with regional routing, whatever your edition. Each AI feature has its own usage history view, for example CORTEX_AI_FUNCTIONS_USAGE_HISTORY and CORTEX_AGENT_USAGE_HISTORY. You also pay for the warehouse that runs an AI query.

If your bill moved and you do not yet know why, our guide to why your Snowflake bill doubled lists the usual causes, and why your cost dashboard might be lying to you covers the reading errors that make a number look wrong.

How do you attribute Snowflake cost to teams, users and queries?

Snowflake supports three attribution methods: object tags on warehouses and users, query tags on individual statements, and per-query credits in QUERY_ATTRIBUTION_HISTORY. Use object tags when a warehouse belongs to one team, user tags or query tags when teams share a warehouse, and per-query credits to find the most expensive work inside any of them.

Snowflake’s attribution guide describes three scenarios.

1. A warehouse used by one team

Tag the warehouse, then join its metering to TAG_REFERENCES. This is Snowflake’s own pattern, for last month:

-- Warehouse credits by cost_center tag, last full month
SELECT tr.tag_name,
       COALESCE(tr.tag_value, 'untagged') AS tag_value,
       SUM(wmh.credits_used_compute) AS total_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY wmh
LEFT JOIN SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES tr
  ON wmh.warehouse_id = tr.object_id
 AND tr.domain = 'WAREHOUSE'
WHERE wmh.start_time >= DATE_TRUNC('MONTH', DATEADD(MONTH, -1, CURRENT_DATE))
  AND wmh.start_time <  DATE_TRUNC('MONTH', CURRENT_DATE)
GROUP BY 1, 2
ORDER BY total_credits DESC;

Basic tagging is available on every edition, and an object can carry up to 50 tags (object tagging). A large “untagged” row is your first to-do.

2. A warehouse shared by several teams

Tag the users instead, and sum per-query credits by user. QUERY_ATTRIBUTION_HISTORY splits a warehouse’s cost among the queries that ran on it, by weighted average of resource use when queries overlap. Know what it leaves out: warehouse idle time, queries of about 100 milliseconds or less, cloud services, serverless features, storage, data transfer, AI token costs and jobs on Adaptive Warehouses. Data is complete from mid-August 2024 and arrives up to 8 hours late.

3. One application running work for many teams

Set a query tag per job, model or dashboard. QUERY_TAG is a string of up to 2,000 characters and can be set for the account, a user or a session, for example ALTER SESSION SET QUERY_TAG = 'COST_CENTER=finance';. Our Snowflake query tags guide shows how to set them from dbt, Python and BI tools.

Reporting cost by role

QUERY_ATTRIBUTION_HISTORY has the user and the query tag but no role column. To report by role, join it to QUERY_HISTORY:

-- Attributed compute credits by role, user and query tag, last 7 days
SELECT qh.role_name,
       qa.user_name,
       COALESCE(NULLIF(qa.query_tag, ''), '(untagged)') AS query_tag,
       COUNT(*) AS queries,
       ROUND(SUM(qa.credits_attributed_compute), 2) AS credits
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY qa
JOIN SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY qh
  ON qh.query_id = qa.query_id
WHERE qa.start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3
ORDER BY credits DESC
LIMIT 25;

Because the view leaves out idle time, the attributed credits will add up to less than the warehouse bill. Snowflake’s examples handle this by spreading the warehouse total across users in proportion to their attributed credits. Decide which approach you use and say so in your reports, or readers will question the numbers.

For more depth, see Snowflake cost by user, role and warehouse, cost per query attribution, and, for dbt teams, reducing the cost of dbt models. Once costs are attributed, the next decision is whether to bill teams for them; see chargeback vs showback and data platform unit economics.

Resource monitors or budgets: which should you use?

Use resource monitors to cap warehouse credits and suspend warehouses when a quota is reached. Use budgets to track all credit usage, including serverless features, against a monthly limit and send notifications. Snowflake’s cost control guide puts it this way: budgets cover serverless features and warehouses, while resource monitors cover warehouses only.

Resource monitor details

A few details from the resource monitor docs matter in practice. A warehouse can belong to only one warehouse-level monitor. A monitor can have one SUSPEND, one SUSPEND_IMMEDIATE and up to five NOTIFY actions. Notifications are off by default. Warehouses can keep using credits briefly after they hit a threshold, so Snowflake suggests suspending at, for example, 90% rather than 100%. Limits do not take the daily 10% cloud services adjustment into account.

-- Snowflake's example: notify at 75%, suspend at 90%, suspend immediately at 110%
USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE RESOURCE MONITOR rm_reporting WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS ON 75 PERCENT DO NOTIFY
           ON 90 PERCENT DO SUSPEND
           ON 110 PERCENT DO SUSPEND_IMMEDIATE;

ALTER WAREHOUSE reporting_wh SET RESOURCE_MONITOR = rm_reporting;

Budget details

Budgets forecast the month and notify you when spend is projected to pass the limit. A one-hour low latency budget costs 12 times as much to run as the default. Budgets can also enforce per-user credit quotas. For a full comparison, read Snowflake budgets vs resource monitors, and for setup steps and examples, Snowflake resource monitors.

How do you catch a Snowflake cost spike early?

Snowflake flags daily cost anomalies for you, with no setup, once an account has 30 days of history. That catches a spike the next day. To hear sooner, add a Snowflake alert that checks hourly warehouse credits against a threshold you choose. Either way, someone still has to trace the spike to the query and person behind it.

Snowflake’s built-in anomaly detection

Cost anomaly detection is always on at account and organization level. See it in Snowsight under Admin > Cost management > Anomalies, or in ACCOUNT_USAGE.ANOMALIES_DAILY. Its limits: it needs at least 30 days of consumption, ignores accounts that used under 10 credits in the last seven days, and sends notifications once a day. At organization level, a spike in one account and a dip in another can cancel out. Custom anomaly monitors, scoped by object tag or service type, are a preview feature.

A same-day alert

For a same-day signal, use an alert. This serverless alert checks every hour whether any warehouse used more than 20 credits in a single hour over the last six hours, and emails you through SYSTEM$SEND_EMAIL. Replace the threshold, integration name and address:

-- Hourly check for a warehouse hour above 20 credits (requires an email notification integration)
CREATE OR REPLACE ALERT warehouse_spike_alert
  SCHEDULE = '60 MINUTE'
  IF (EXISTS (
    SELECT 1
    FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
    WHERE start_time >= DATEADD(hour, -6, CURRENT_TIMESTAMP())
      AND credits_used_compute > 20
  ))
  THEN CALL SYSTEM$SEND_EMAIL(
    'my_email_integration',
    'data-platform@example.com',
    'Snowflake warehouse spike',
    'A warehouse used more than 20 credits in one hour. Check WAREHOUSE_METERING_HISTORY.'
  );

ALTER ALERT warehouse_spike_alert RESUME;

New alerts start suspended, hence the RESUME. Because WAREHOUSE_METERING_HISTORY can be up to 3 hours behind, this alert fires hours after the spike, not minutes, and it will repeat each hour while the row stays in its six-hour window. The alert itself also uses serverless credits.

Once you know a spike happened, work out where it came from: trace a Snowflake cost spike to the query and user walks through it step by step, and cost anomaly detection explains how detection methods differ.

What does a simple Snowflake cost monitoring routine look like?

A workable routine is a short daily check of credits by service and warehouse, a weekly review of attribution and the most expensive queries, and a monthly reconciliation in currency against budgets and the contract. It takes minutes a day if you save the queries above, and it turns monitoring into a habit rather than an investigation.

Monthly reports should wait until the currency views settle, since they can change until month close. Before a renewal, use the same data to forecast your commitment; see Snowflake contract renewal. When monitoring shows where the money goes, the Snowflake cost optimization guide covers what to change.

How Seemore helps with Snowflake cost monitoring

The routine above works, but it depends on views that run hours behind and on someone reading them. Seemore’s Cost Anomaly Detection compares spend across your accounts, warehouses and services against the last 14 days of your own history and hands you the root cause when something drifts, replacing days of investigation with a clear answer. Real Time Monitoring shows every connected account live, down to the exact query behind a spike, and the Seemore platform attributes cost by job, user, domain and data product. You can also ask Seemore Assistant about your environment in plain language instead of writing the SQL above.