What you will be able to do
- Explain how Snowflake detects cost anomalies at the account, organization and monitor level, and what the detection needs before it works
- Scope an anomaly monitor with tags, service types and a credit family to watch serverless and AI consumption
- Track Snowpark Container Services and AI credit usage and investigate a spike to find its cause
1.Built-in cost anomaly detection
An unexpected jump in credits can be the first sign of trouble: a stolen credential running heavy queries, a container service that won't stop, or someone misusing an AI endpoint. Snowflake flags a cost anomaly when a day's consumption falls above or below the range expected from past usage. Dips count as well as spikes.
Account-level and organization-level detection is always on and needs no setup. There is no detection pipeline for you to build or pay for. It does have some blind spots. The algorithm needs at least 30 days of history before it can flag anything. It also ignores changes in accounts that used fewer than 10 credits in the last seven days. So a new or almost idle account may not be covered at first.
That is why account-level detection matters even when you watch the organization view. To check history with SQL, query ACCOUNT_USAGE.ANOMALIES_DAILY (in credits) for the current account, or ORGANIZATION_USAGE.ANOMALIES_IN_CURRENCY_DAILY (in currency) across accounts. Each row shows one day's consumption and whether it counted as an anomaly.
Checkpoint 1 of 6· Check yourself
An account was created 20 days ago and has already used several hundred credits. A sudden spike happens today. Will built-in account-level detection flag it?
Detection is always on, but the algorithm can't flag anomalies until it has 30 days of consumption to compare against.
“The algorithm that detects cost anomalies requires at least 30 days of consumption before it can identify anomalies.”Source: docs.snowflake.com
Sources1
2.Trust Center scanner packages and their cost
Security tooling consumes credits too. The Trust Center groups its scanners into scanner packages: Security Essentials, CIS Benchmarks, Threat Intelligence and AI Security. The Trust Center incurs serverless compute cost when it scans, and that cost is metered under SERVICE_TYPE = TRUST_CENTER in METERING_HISTORY and METERING_DAILY_HISTORY.
Packages are deactivated by default, except Security Essentials. Security Essentials is enabled by default and can't be deactivated. Its regular fixed-schedule runs don't incur serverless compute cost, and you can't change that schedule. Any other run of it does incur incremental serverless charges. The CIS Benchmarks package evaluates your account against the CIS Snowflake Benchmarks and runs once a day by default, on a schedule you can change.
Checkpoint 2 of 6· Exam question
A team is deciding which Trust Center scanner packages to enable for cost and coverage. Which statements are accurate? (Select TWO.)(Select 2)
Correct answers: C, E — Optional packages such as CIS Benchmarks and Threat Intelligence incur serverless compute charges when they run, so enabling them is a cost decision.; The Security Essentials scanner package is enabled by default, cannot be deactivated, and runs on its fixed schedule without serverless compute charges.
- A. Incorrect: Security Essentials runs without serverless compute charges, so the claim that every package bills is wrong.
- B. Incorrect: scanners are serverless and do not run on the default warehouse, so warehouse resource monitors do not govern them.
- C. Correct: other packages use serverless compute when they run, so each one trades extra coverage for credits.
- D. Incorrect: charges depend on the package, not on the edition, and there is no Business Critical-only billing rule for scanners.
- E. Correct: Security Essentials is on by default, cannot be turned off, and does not add serverless cost.
- F. Incorrect: Security Essentials is independent of the optional packages, and disabling one does not stop another from raising findings.
3.Anomaly monitors: narrowing the scope
Account-level detection can miss a spike in one team's warehouses if total account usage still looks normal. An anomaly monitor (a preview feature) runs the same algorithm on a narrower scope. You define that scope with resource-level object tags and account-level service types. Consumption that matches *any* part of the scope is included and counted once. A service type you add is counted in full for the whole account. That lets you watch, for example, all SERVERLESS_TASK or TRUST_CENTER usage in one monitor.
Each monitor tracks exactly one credit family, because credits and AI credits are different units and can't be added together.
| Credit family | Covers |
|---|---|
| CREDITS | Traditional consumption, such as virtual warehouse compute, serverless tasks, and Snowpipe |
| AI-CREDITS | AI-related services, such as Cortex Search, Cortex Agents, and AI functions |
Monitors also add work to look after. To use a tag in a monitor you need APPLYBUDGET on that tag. Each account can have up to 20 monitors, and each monitor up to 20 tag pairs and 20 service types. Monitors can't span accounts. They don't support user tags, and they can't split a shared resource by user, which is something only budgets can do. Snowflake can't tell when a resource is retagged, so after retagging you must recalculate the monitor by hand. A deleted monitor can't be recovered.
Checkpoint 3 of 6· Check yourself
When you build a monitor in Snowsight, why do you choose the credit family before adding service types?
The credit family filters both the service types you may add and the tagged consumption the monitor counts. Notifications are set separately, monitors always report in credits, and monitors are always single-account.
“This determines which service types you can add, and limits tag-attributed consumption to that credit family.”Source: docs.snowflake.com
4.Watching Snowpark Container Services and AI consumption
Advanced features use compute you don't size per query, which makes them easy to abuse quietly. Serverless features such as tasks, alerts, classification and the Trust Center use Snowflake-managed compute and each appears as its own service type (SERVERLESS_TASK, SERVERLESS_ALERTS, SENSITIVE_DATA_CLASSIFICATION, TRUST_CENTER). To spot a serverless spike, group METERING_HISTORY by SERVICE_TYPE and compare recent days with earlier ones. A service type that suddenly jumps is the signal, and you can watch it with a monitor that includes that service type.
Snowpark Container Services runs on compute pools, and the number and instance family of the nodes decide what it costs. A pool is billed while it is IDLE, ACTIVE, STOPPING or RESIZING, but not while STARTING or SUSPENDED. A pool that never reaches SUSPENDED therefore keeps costing credits, and the docs recommend using AUTO_SUSPEND to optimize pool expenses. Any steady SPCS usage that doesn't match a known workload deserves a look. The SNOWPARK_CONTAINER_SERVICES_HISTORY view shows hourly SPCS credits on their own. METERING_HISTORY and METERING_DAILY_HISTORY show them under SERVICE_TYPE = SNOWPARK_CONTAINER_SERVICES, and ENTITY_ID/NAME identify the entity that consumed the credits.
AI features are metered under several service types, and the credit family depends on which one. Cortex functions and Cortex Analyst fall under AI_SERVICES, which the service types list shows in Credits, so a CREDITS monitor can cover it. Others, such as AI_FUNCTIONS, CORTEX_AGENTS and CORTEX_SEARCH, are listed in AI Credits and need an AI-CREDITS monitor. Check the Unit column in the service types list before choosing the family.
Checkpoint 4 of 6· Check yourself
A team has a CREDITS-family monitor on resources tagged team=support. Their tagged Cortex Search service suddenly uses far more AI credits. Why doesn't the monitor flag it, and what fixes it?
A monitor counts only consumption in its own credit family, so AI usage needs its own AI-CREDITS monitor on the same tags.
“To track both traditional consumption and AI consumption for the same set of tags, create two monitors, one for each credit family.”Source: docs.snowflake.com
Checkpoint 5 of 6· Exam question
A data science team reports that a Snowpark Container Services service was dropped, yet the account still shows steady credit consumption under the container services category overnight. The compute pool was created with MIN_NODES = 2 and no auto-suspend change. What is the most likely reason?
Correct answer: B — The compute pool keeps running its minimum nodes while active, and compute pool nodes bill per hour whether or not any service is running on them.
- A. Incorrect: image repositories are stage-like storage and have no background indexing job billed as serverless credits.
- B. Correct: compute pools bill for nodes while they are active, independent of services, so idle pools with a minimum node count keep consuming credits until suspended, with AUTO_SUSPEND_SECS or manually.
- C. Incorrect: no such 24-hour grace-period billing exists; egress is billed as data transfer, not as compute pool credits.
- D. Incorrect: a warehouse used to run the CREATE SERVICE statement bills under warehouse metering, not the container services category, and auto-suspends on its own setting.
5.Investigating a spike and routing alerts
When an anomaly fires, open it from Admin » Cost management » Anomalies in Snowsight. For an account-level anomaly, the side panel shows top consumption drivers by service type, top warehouses, and top queries, which can lead you to the user who ran them. For an organization-level anomaly, it shows the accounts with the biggest change. The side panel doesn't work for monitor anomalies. For those, use Cortex Code: highlight the spike and ask, for example, "Why did this cost spike occur?"
Keep data latency in mind. METERING_HISTORY can be up to three hours behind, cloud services credits up to six hours, and Snowpipe Streaming up to 12 hours. Detection is daily, so it is not a real-time intrusion alarm.
Notifications go to verified email addresses, with separate lists for the account, the organization and each monitor. Monitors can only send email. To send alerts to Slack, SMS or a webhook, use a notification integration, which works for account-level and organization-level anomalies only.
Checkpoint 6 of 6· Check yourself
The SOC wants anomalies from a custom monitor sent to its webhook. What is possible?
Monitors support email only, and their results aren't in the ANOMALIES_DAILY views. Notification integrations apply to account-level and organization-level anomalies.
“To send anomaly notifications to Slack, SMS, or a webhook, use a notification integration, which applies to account-level and organization-level anomalies.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Watching organization-level anomalies is enough to catch a compromised account.Why is that wrong?
Organization-level detection uses total consumption, so a spike in one account can be cancelled out by a dip in another. Account-level detection is needed to see it.
Covered in Built-in cost anomaly detection
2.Because Security Essentials is always on, the Trust Center never adds serverless cost.Why is that wrong?
Only the Security Essentials fixed-schedule runs are free of serverless compute cost. Any other run of it, and the other enabled packages, incur serverless charges metered as TRUST_CENTER.
Covered in Trust Center scanner packages and their cost
3.An anomaly monitor can split a shared warehouse's cost by the users who ran queries on it.Why is that wrong?
Monitors give all of a tagged resource's consumption to the monitor. Splitting cost by user requires a budget.
Covered in Anomaly monitors: narrowing the scope
4.A compute pool with no running jobs costs nothing.Why is that wrong?
Compute pools are billed in the IDLE state as well as ACTIVE, so an idle pool without auto-suspend keeps using credits.
Covered in Watching Snowpark Container Services and AI consumption
Practise it for real
Check where serverless, container and AI credits are going in an account, and whether any day has been flagged as anomalous.
1.Query ACCOUNT_USAGE.METERING_HISTORY grouped by SERVICE_TYPE over the last 30 days.
Why: Each security, serverless and advanced feature has its own service type, so this shows the share each one uses.
You should see: Rows such as WAREHOUSE_METERING, TRUST_CENTER, SERVERLESS_TASK, AI_SERVICES or SNOWPARK_CONTAINER_SERVICES with their credits.
2.Filter the same view on SERVICE_TYPE = 'SNOWPARK_CONTAINER_SERVICES' and group by NAME and ENTITY_ID.
Why: This shows which entities used container credits, so you can spot one you don't recognize.
You should see: One line per consuming entity with its hourly credits.
3.Query ACCOUNT_USAGE.ANOMALIES_DAILY for the same period.
Why: This shows which days the built-in detector flagged, so you can match them to the service types above.
You should see: Daily consumption rows marked as anomalous or not. If the account has less than 30 days of history, no anomalies will be flagged yet.
4.In Snowsight, build an AI-CREDITS scope on a team tag and review it before saving.
Why: Testing a scope first shows whether it would have caught past AI spikes.
You should see: A chart of AI credit usage for that scope with its expected range.
Stuck? Get a nudge
Remember that METERING_HISTORY can be up to three hours behind, so the latest hours may look lower than they really are.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Account-level and organization-level detection is always on and requires no configuration.”
↩︎ Built-in cost anomaly detection“If your consumption in the last seven days was less than 10 credits, Snowflake does not identify changes as an anomaly.”
↩︎ Built-in cost anomaly detection“Execute queries against the ANOMALIES_DAILY view in the ACCOUNT_USAGE schema to gain insights into whether cost anomalies occurred in the current account.”
↩︎ Built-in cost anomaly detection“so a spike inside one team’s warehouses is flagged even when total account consumption looks normal.”
↩︎ Anomaly monitors: narrowing the scope“Credits and AI credits are different units of measure and can’t be added together.”
↩︎ Anomaly monitors: narrowing the scope“To include a tag in a monitor’s scope, you need the APPLYBUDGET privilege on that tag.”
↩︎ Anomaly monitors: narrowing the scope“An organization-level anomaly is based on the aggregate consumption of all accounts in the organization.”
↩︎ Exam trap 1“If you need to attribute the consumption of a shared resource by user, use a budget instead.”
↩︎ Exam trap 3“For example, a spike in one account and a dip in another can offset each other, so no organization-level anomaly is flagged.”
↩︎ Prediction“The algorithm that detects cost anomalies requires at least 30 days of consumption before it can identify anomalies.”
↩︎ Checkpoint“To track both traditional consumption and AI consumption for the same set of tags, create two monitors, one for each credit family.”
↩︎ Checkpoint - 2.
“Is enabled by default. You can’t deactivate it.”
↩︎ Trust Center scanner packages and their cost“Runs regularly on a fixed schedule without incurring any serverless compute cost. You can’t change this schedule.”
↩︎ Trust Center scanner packages and their cost“Incurs incremental charges for the serverless compute cost for any other run.”
↩︎ Exam trap 2 - 3.
“The Trust Center incurs serverless compute cost when it scans your Snowflake environment for security vulnerabilities.”
↩︎ Trust Center scanner packages and their cost - 4.
“Deleting a monitor permanently removes its configuration, anomaly history, and notification list.”
↩︎ Anomaly monitors: narrowing the scope“The side panel isn’t available for anomaly monitors. To investigate an anomaly that a monitor detected, use Cortex Code.”
↩︎ Investigating a spike and routing alerts“Monitors support email notifications only.”
↩︎ Investigating a spike and routing alerts“This determines which service types you can add, and limits tag-attributed consumption to that credit family.”
↩︎ Checkpoint“To send anomaly notifications to Slack, SMS, or a webhook, use a notification integration, which applies to account-level and organization-level anomalies.”
↩︎ Checkpoint - 5.https://docs.snowflake.com/en/developer-guide/snowpark-container-services/accounts-orgs-usage-viewsOfficial docs
“The SNOWPARK_CONTAINER_SERVICES_HISTORY view offers credit usage information (hourly consumption) exclusively for Snowpark Container Services.”
↩︎ Watching Snowpark Container Services and AI consumption“To optimize compute pool expenses, you should leverage the AUTO_SUSPEND feature”
↩︎ Watching Snowpark Container Services and AI consumption“You incur charges for a compute pool in the IDLE, ACTIVE, STOPPING, or RESIZING state”
↩︎ Exam trap 4 - 6.
“AI_SERVICES: See Snowflake Cortex AI Functions (including LLM functions) and Cortex Analyst.”
↩︎ Watching Snowpark Container Services and AI consumption“Latency for the view may be up to 180 minutes (3 hours), except for the CREDITS_USED_CLOUD_SERVICES column.”
↩︎ Investigating a spike and routing alerts - 7.
“Usage of Snowflake AI and ML services including Cortex functions.”
↩︎ Watching Snowpark Container Services and AI consumption - 8.
“Serverless features use compute resources that are managed by Snowflake instead of using virtual warehouses.”
↩︎ Watching Snowpark Container Services and AI consumption