Snowflake Cloud Services Credits: How the 10% Rule Works (2026)

Snowflake cloud services credits are billed only on days when cloud services use passes 10% of that day’s virtual warehouse credits. Even then, you pay only for the excess. Snowflake works this out for each UTC day, and serverless usage does not count toward the 10%. This guide explains the rule, the METERING_DAILY_HISTORY columns, a worked example, what drives high usage, and how to reduce it. Every fact and figure in this guide was checked against Snowflake’s documentation.

This article is part of our guide to Snowflake pricing explained.

What are Snowflake cloud services credits?

Snowflake cloud services credits pay for the layer that coordinates your account. It authenticates users, enforces security, compiles and optimizes queries, and handles query caching. Snowflake manages that compute for you, and it uses credits just as warehouses do. Often only part of that use is billed.

Its services also include metadata management and infrastructure management, per Snowflake’s key concepts page. The Service Consumption Table says cloud services is charged at 4.4 credits per hour of cloud services use. For how credits turn into dollars, see our guide to how much a Snowflake credit costs.

When does Snowflake charge for cloud services credits?

Snowflake charges for cloud services only on days when cloud services use is more than 10% of that day’s virtual warehouse usage. You pay for the part above 10%. The check runs daily in the UTC time zone at that day’s credit price, and the monthly adjustment is the sum of the daily ones.

How is the daily adjustment calculated?

Snowflake’s page on understanding compute cost gives the rule. For each UTC day:

1. Add up the day’s virtual warehouse credits. This is the base.
2. Multiply the base by 10%. This is the day’s allowance.
3. Compare the allowance with the cloud services credits used. The adjustment is the lesser of the two, shown as a negative number.
4. You are billed for cloud services used plus the adjustment, which is negative. In other words, you pay for use minus the part the allowance covers.

Unused allowance does not carry over. The monthly adjustment is the sum of the daily ones, so Snowflake notes it “may be significantly less than 10%”. On a day under the line, the adjustment equals the cloud services used, so nothing extra is billed.

What counts toward the 10%?

Only virtual warehouse credits form the base. The documentation’s own example labels that column “Compute Credits Used (Warehouses only)”. Serverless usage is outside it in two ways:

• Serverless compute is not in the base. Snowflake states that serverless compute does not factor into the 10% adjustment.
• Serverless cloud services do not count toward the adjustment. The Service Consumption Table says cloud services usage tied to serverless features or Snowpark Container Services compute does not contribute to the adjustment. Where a serverless feature uses cloud services, Snowflake bills them with its compute as one line item. Our guide to Snowflake serverless costs lists each rate.

However, one trap follows from this. CREDITS_USED_COMPUTE in METERING_DAILY_HISTORY includes serverless compute and Openflow, so do not rebuild the 10% base by summing it. Use Snowflake’s adjustment column instead.

The base grows with warehouse credits per hour. For example, a Gen1 X-Small warehouse that runs all day uses 24 credits and adds 2.4 credits of allowance. A Gen2 X-Small on AWS uses 1.35 credits per hour, so 32.4 credits a day and 3.24 credits of allowance (Table 1(b) of the Consumption Table, effective 29 October 2026). See warehouse sizes and credits per hour for each size.

Contract terms can differ. The Consumption Table charges capacity accounts for cloud services only if the term started on or after February 1, 2020, so check your order form.

What do the METERING_DAILY_HISTORY columns mean?

METERING_DAILY_HISTORY reports daily credits by service type. CREDITS_USED_CLOUD_SERVICES is cloud services use before the adjustment. CREDITS_ADJUSTMENT_CLOUD_SERVICES is a negative number that removes the part Snowflake does not bill. CREDITS_BILLED is the total you pay for. Data arrives up to 3 hours late.

Snowflake documents the METERING_DAILY_HISTORY view with these columns:

• CREDITS_USED_COMPUTE: credits for warehouses, serverless compute and Openflow in the day.
• CREDITS_USED_CLOUD_SERVICES: credits cloud services used in the day, before any adjustment.
• CREDITS_ADJUSTMENT_CLOUD_SERVICES: the adjustment, a negative value such as -9.
• CREDITS_BILLED: the sum of the three columns above.

However, most other views do not apply the adjustment. Snowflake says Snowsight and a majority of views show cloud services credits without this daily adjustment. That includes the CREDITS_USED column in WAREHOUSE_METERING_HISTORY, so its totals can be higher than your bill.

This query finds the days when cloud services were billed. It builds on the example on Snowflake’s view page, with service type and billed credits added and the filter changed to billed cloud services above zero. Snowflake controls access to these views through SNOWFLAKE database roles.

-- Days in the last 30 days when cloud services credits were billed. Latency: up to 3 hours.
-- Role: ACCOUNTADMIN, or a role granted the SNOWFLAKE.USAGE_VIEWER database role.
SELECT usage_date,
       service_type,
       credits_used_compute,
       credits_used_cloud_services,
       credits_adjustment_cloud_services,
       credits_used_cloud_services + credits_adjustment_cloud_services AS billed_cloud_services,
       credits_billed
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD(day, -30, CURRENT_DATE())
  AND credits_used_cloud_services + credits_adjustment_cloud_services > 0
ORDER BY billed_cloud_services DESC;

Read SERVICE_TYPE before you blame the 10% rule. Snowflake does not document which row carries the adjustment, so check SERVICE_TYPE on each billed row. Add this check to your daily routine. Our guide to Snowflake cost monitoring lays out a daily routine.

How does the 10% rule work in a worked example?

In this illustrative example, day A has 200 warehouse credits and 5 cloud services credits, so the 20-credit allowance covers all 5. Day B has 20 warehouse credits and 8 cloud services credits, so the 2-credit allowance covers only 2, and you pay for 6.

All numbers are made up.

Two points stand out:

• Day A leaves 15 credits of allowance unused. They do not carry over to day B.
• The daily rule can cost more than a pooled one. Across both days, cloud services is only 5.9% of warehouse credits. Yet 6 credits are billed, because Snowflake applies the allowance day by day. A single pooled allowance of 22 credits would have covered all 13.

At $3.00 per credit, the 6 billed credits cost $18.00. That rate is for the Enterprise edition, on demand, in AWS US East (Northern Virginia), from Table 2(a) of the Consumption Table effective 29 October 2026. Your rate depends on your edition, cloud, region and contract.

What drives high cloud services credits?

Snowflake documents seven usage patterns that drive cloud services credits. A single simple call is negligible, but very frequent calls, heavy metadata work, heavy file listing and complex statements can add up. Four of the seven involve work that uses only cloud services compute: INFORMATION_SCHEMA queries, SHOW commands, DDL and cloning, and the file listing step of COPY.

Snowflake’s guide to optimizing cloud services for cost lists these patterns:

• High-frequency simple queries. A statement such as SELECT 1 or SELECT CURRENT_SESSION() uses a negligible amount. Tens of thousands a day, though, add up.
• High-frequency INFORMATION_SCHEMA queries. These consume only cloud services resources, so the same frequency warning applies.
• High-frequency SHOW commands. SHOW commands are entirely metadata operations. They typically come from data applications and can also come from third-party tools.
• Frequent DDL and cloning. These are also metadata operations. Creating or dropping large schemas or tables often, or cloning databases for backup, can use a lot.
• COPY commands with poor selectivity. Listing files in S3 uses only cloud services compute, so a COPY with poor selectivity lists more files than it needs.
• Single-row inserts and fragmented schemas. Snowflake is not an OLTP system. A design with one schema per customer can cause many loads and a lot more metadata to maintain.
• Complex SQL. Many joins or Cartesian products, large IN lists and very large queries all have long compilation times.

In addition, Snowflake names partner tools and session parameter changes as candidates when a warehouse shows a high cloud services ratio.

How do you find the queries behind cloud services credits?

Query SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY and sum CREDITS_USED_CLOUD_SERVICES by user, warehouse or query type for the day you flagged. Per-query values are not adjusted by the 10% rule, so they can add up to more than you were billed. The view arrives up to 45 minutes late.

Pick a day from the first query, then break it down. Set the session to UTC first, so the day matches the one Snowflake bills on. In this view, WAREHOUSE_NAME is the warehouse the query ran on, “if any”. Keep the rows with no warehouse name, because some queries run without one.

-- Cloud services credits by query type, user and warehouse for one UTC day. Latency: up to 45 minutes.
-- Role: ACCOUNTADMIN, or a role granted the SNOWFLAKE.GOVERNANCE_VIEWER database role.
-- Values are before the 10% adjustment, so they can exceed what you were billed.
ALTER SESSION SET TIMEZONE = UTC;

SELECT query_type,
       user_name,
       warehouse_name,
       COUNT(*) AS queries,
       SUM(credits_used_cloud_services) AS cloud_services_credits
FROM snowflake.account_usage.query_history
WHERE start_time >= TO_TIMESTAMP_LTZ('2026-11-03')
  AND start_time <  DATEADD(day, 1, TO_TIMESTAMP_LTZ('2026-11-03'))
GROUP BY query_type, user_name, warehouse_name
ORDER BY cloud_services_credits DESC
LIMIT 25;

Replace the date with the day you flagged. Next, look for repeated statements. Thousands of runs with small credits each match the high-frequency patterns above.

-- Repeated statement patterns ranked by cloud services credits for one UTC day. Latency: up to 45 minutes.
-- Role: ACCOUNTADMIN, or a role granted the SNOWFLAKE.GOVERNANCE_VIEWER database role.
ALTER SESSION SET TIMEZONE = UTC;

SELECT query_parameterized_hash,
       ANY_VALUE(LEFT(query_text, 100)) AS sample_text,
       COUNT(*) AS runs,
       SUM(credits_used_cloud_services) AS cloud_services_credits
FROM snowflake.account_usage.query_history
WHERE start_time >= TO_TIMESTAMP_LTZ('2026-11-03')
  AND start_time <  DATEADD(day, 1, TO_TIMESTAMP_LTZ('2026-11-03'))
GROUP BY query_parameterized_hash
ORDER BY cloud_services_credits DESC
LIMIT 20;

Do not use QUERY_ATTRIBUTION_HISTORY for this. Snowflake says its per-query credits exclude cloud services costs. Once you have a user and a query, our guide to tracing a cost spike to the query and user shows the next steps.

How can you reduce cloud services credits?

Fix the pattern, not the total. Snowflake’s documentation recommends reviewing how often repeated queries run, asking partners to update their tools, narrowing file listings in COPY, cloning at a finer grain, and loading in batches. Do not run extra warehouse work to raise the allowance.

Each recommendation below comes from the same cloud services optimization guide:

1. Review how often queries run. Check that the frequency of simple queries, SHOW commands and INFORMATION_SCHEMA queries fits the use case. For partner tools, ask the partner about their plans.
2. Update JDBC-based tools. If many SELECT CURRENT_SESSION() queries come from partner tools on the JDBC driver, confirm they use getSessionId(), which uses caching.
3. Narrow COPY file listings. Add a date prefix to your S3 bucket structure, so COPY lists only the files it needs.
4. Review how you clone. Keep cloning, because it uses only a fraction of the resources of a deep copy. Check that clones are as granular as possible and not too frequent. For example, you might clone individual tables rather than whole schemas.
5. Load in batches. Use bulk loads rather than single-row inserts. A shared schema is more efficient than one schema per customer.
6. Review complex SQL. Confirm that queries with many joins, large IN lists or very large statements do what you intend. Snowflake supports them and charges only for resources used.

However, one option has a catch. You can query an ACCOUNT_USAGE view instead of INFORMATION_SCHEMA. Snowflake says that moves the work onto a virtual warehouse rather than cloud services. That changes where the credits land. It does not make them free. ACCOUNT_USAGE views have some latency, up to a few hours depending on the view, while Information Schema views have none, so check that your tool can wait.

Raising the allowance is a poor fix, because each extra cloud services credit you want covered needs 10 more warehouse credits, and you pay for those.

Do resource monitors count cloud services credits?

Yes. A resource monitor counts all cloud services credits that support its warehouses, including the part Snowflake never bills. Snowflake says monitor limits do not take the daily 10% adjustment into account, so a monitor can reach its quota earlier than your invoice suggests.

Snowflake’s resource monitor page gives an example. A monitor has a limit of 1,000 credits. Warehouses consume 700 credits and cloud services consume 300 in the same interval. That triggers the alert, even if part of the 300 is never billed.

A warehouse-level monitor can monitor cloud services but cannot suspend them. After a warehouse is suspended, later queries against it can still add cloud services cost. Our comparison of Snowflake budgets and resource monitors shows how to combine the two.

How Seemore helps with cloud services credits

The queries above are a manual routine that depends on views lagging by up to 3 hours 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.