SNOWFLAKE ANOMALY DETECTION
Snowflake Anomaly Detection: Snowflake ML Anomaly Detection and Outlier Detection Compared
Anomaly detection across every Snowflake table, watching freshness, volume, schema, and distribution, with no model object to create per series and no rules to author per table. Read only connection, alerts in Slack and PagerDuty, from 99 dollars a month.
14-day trial, no credit card, read-only connection
Alerted #data-eng 0.8s ago.
Downstream impact · consumers at risk
Does Snowflake have built in anomaly detection?
Yes, as a model object you create rather than as a monitoring system. SNOWFLAKE.ML.ANOMALY_DETECTION trains a gradient boosting model on a timestamp column and a target column, and the DETECT_ANOMALIES method scores new rows, returning FORECAST, LOWER_BOUND, UPPER_BOUND, and an IS_ANOMALY flag. Snowflake data metric functions cover the rule side, with system metrics such as NULL_COUNT, DUPLICATE_COUNT, ROW_COUNT, and FRESHNESS on a schedule. Both need Enterprise Edition for the quality monitoring path, and neither decides what normal means per table, deduplicates repeat firings, or pages the engineer who owns the dataset. Dataobservability connects to Snowflake read only, learns each table baseline from history, and alerts on freshness, volume, schema, and distribution breaks across every database, from 99 dollars a month.
Last updated August 2026
Side by side
Snowflake anomaly detection compared
Swipe to see all columns →
| How to detect anomalies in Snowflake | What it catches | What you build and operate | Documented limits (Snowflake docs, August 2026) |
|---|---|---|---|
| SNOWFLAKE.ML.ANOMALY_DETECTION, unsupervised (LABEL_COLNAME set to an empty string) | Values falling outside a learned prediction interval on a time series | Model creation per series, a schedule, a results table, thresholds, dedupe, and alert routing | Needs at least 12 rows per series for non naive results and 60 rows for non linear results. Anomalies can only be detected in test data, never in the training data, and every test timestamp must be later than the training timestamps |
| SNOWFLAKE.ML.ANOMALY_DETECTION, supervised (LABEL_COLNAME set to a Boolean column) | Anomalies that resemble ones you have already labeled | A labeled Boolean column kept current as new failure modes appear, plus everything above | Requires known anomalies already labeled. The incidents that cost the most are usually the ones nobody has labeled yet |
| The DETECT_ANOMALIES method on a trained model | Rows flagged IS_ANOMALY, returned with FORECAST, LOWER_BOUND, UPPER_BOUND, PERCENTILE, and DISTANCE | Somewhere to store output, and a decision about which flagged rows are worth waking someone for | Runs at roughly one second per 100 rows regardless of warehouse size, so a larger warehouse does not make inference faster |
| System data metric functions in the SNOWFLAKE.CORE schema | Metric breaks across accuracy, freshness, schema, statistics, uniqueness, and volume, including NULL_COUNT, DUPLICATE_COUNT, ROW_COUNT, FRESHNESS, and SCHEMA_CHANGE_COUNT | One association per metric per column or table, plus the schedule and a place to read results | Requires Enterprise Edition. Limited to 50,000 total DMF associations per account. Cannot be set on hybrid tables or streams. The default schedule runs once every hour |
| Custom data metric functions | Business rules the system metrics do not express | The SQL for each rule, and its maintenance every time a column is renamed or retyped | Same Enterprise Edition requirement and the same 50,000 association ceiling. Every rule is still one statement about one column, authored and owned by you |
| Dataobservability | Freshness, volume, schema, and distribution breaks across every table | A read only connection, no agent | Covers the connected warehouses (Snowflake, BigQuery, Databricks, Redshift) and dbt. Systems outside them are not monitored |
Positioning and pricing models are summarized in good faith from each vendor's public pages, August 2026. Verify current terms with the vendor.
What you get
What a monitoring layer adds on top of the Snowflake primitives
One connection instead of one model object per series
The Snowflake ML function is scoped to a series: a timestamp column, a target column, and a model you create and train. That is a clean fit for the handful of metrics on a leadership dashboard. Across a warehouse it means creating, naming, permissioning, and retraining a schema level object for every series you decided mattered, and quietly missing everything you did not. Metadata driven monitoring inverts that: the table list is the input, so coverage is the default rather than a project.
Baselines that already know your table is quiet on Sunday
Most false alarms are not statistical failures, they are calendar failures. A table loaded hourly on weekdays and never at weekends is not broken on Saturday, and a fixed threshold cannot tell the difference. Baselines derived from each table's own load history encode weekday patterns, month end spikes, and the batch that lands at 04:15, without anyone writing an exception for them.
Alerts that arrive where your on call engineer already is
A query that returns rows where IS_ANOMALY is true is a result set, not an alert. Getting from there to a paged engineer means a scheduled task, a state table so the same anomaly does not fire twelve times, an ownership map, and an integration. Routing into Slack and PagerDuty per dataset owner is the difference between a signal that gets acted on and a channel people mute in week three.
Detection that works on history, not only on the future
Snowflake documents that anomalies can only be detected in test data, and that test timestamps must all be greater than the training timestamps. That rules out pointing the function at last quarter to ask what you missed. Monitoring built on stored metric history can backfill, which matters most in the week after an incident when somebody asks how long the problem had been running.
No Enterprise Edition gate on the quality path
Snowflake data quality monitoring with data metric functions requires Enterprise Edition. For teams on Standard, the native rule based route is simply unavailable, and an edition upgrade is a much larger commitment than a monitoring tool. A platform that reads metadata over a normal read only connection has no edition floor.
Anomalies that arrive with the blast radius attached
A flagged row is a fact. What the person on call needs at 2am is the list of models and dashboards downstream of it. Because monitoring and column level lineage live in the same system, a distribution break on a source field arrives with the specific downstream dependencies that read it, instead of sending someone to a catalog to work it out by hand.
How it works
From connected to caught
Connect Snowflake with a read only role
Create a role with read access to the databases you want watched. Dataobservability reads INFORMATION_SCHEMA, table metadata, and query history to build the table inventory and the freshness and volume picture, so table contents are not copied out of Snowflake. Setup is a read-only connection with no agent, no warehouse changes, and no pipeline changes.
Let baselines build before you tune a single threshold
Give it a few days of history per table so seasonality becomes visible. Tuning thresholds before a baseline exists is how teams generate alert fatigue in the first week and lose trust in the monitoring by the second. The correct amount of configuration on day one is close to none.
Write rules only for the invariants statistics cannot know
Learned baselines catch drift, outages, and distribution shifts. They cannot know that a discount percentage must never exceed 40, or that every order must carry a valid region code. Encode those specific business invariants as custom checks and leave the general shape of the data to the baselines. That split is what keeps the rule set finite instead of growing forever.
Route by dataset owner, then read back what actually fired
Send alerts to the team that owns each database or schema rather than to one shared channel. After two weeks, review the log: monitors that never fired on a real problem should be relaxed, and any incident that reached you through a complaining stakeholder should become a monitor. Monitoring that is never pruned becomes noise, and noise becomes muted.
What SNOWFLAKE.ML.ANOMALY_DETECTION actually does, in the documented detail that matters
Snowflake ships a genuine anomaly detection capability, and it is more specific than most write ups suggest. You create a schema level object with CREATE SNOWFLAKE.ML.ANOMALY_DETECTION, pointing it at training data that needs, at minimum, a timestamp column with granularity no finer than one second and a target column holding the quantity you care about. Training runs unsupervised when LABEL_COLNAME is set to an empty string, and supervised when you pass a Boolean column marking known anomalies, which mainly helps the model avoid overfitting to outliers already present in the training window. Under the surface it is a gradient boosting machine, using differencing for non stationary trends, auto regressive lags, rolling averages, and cyclic calendar variables generated from the timestamp. You then call the DETECT_ANOMALIES method on the model and get back a result set with SERIES, TS, Y, FORECAST, LOWER_BOUND, UPPER_BOUND, IS_ANOMALY, PERCENTILE, and DISTANCE. There are also EXPLAIN_FEATURE_IMPORTANCE and SHOW_TRAINING_LOGS methods, the latter being genuinely useful when one series in a multi series training run fails. The data requirements are modest on paper and consequential in practice. Two rows will train a model. Twelve rows per series are needed before results stop being naive, and sixty before they can be non linear, which means a table with three weeks of daily history produces a model that is technically valid and statistically thin. Multi series training tops out at five million rows per series on a standard warehouse, and Snowflake recommends a Snowpark optimized warehouse beyond that or when you pass five or more exogenous variables. Worth knowing before you plan capacity: the documentation is explicit that a larger warehouse size does not improve training time.
The default that quietly flags one percent of your rows
The single most important parameter is prediction_interval, passed inside CONFIG_OBJECT, and its default is 0.99. That is not a confidence level in the reassuring sense. It means anything falling outside the 99 percent prediction interval is marked as an anomaly, so by construction roughly one percent of rows come back flagged. On a ten million row table, a default configured run returns on the order of one hundred thousand rows with IS_ANOMALY set to true. Snowflake documentation says as much, and recommends setting the value very close to 1.0, suggesting 0.9999 or even closer. This is the detail that decides whether a proof of concept succeeds or collapses. Teams run the function against a real table, see an enormous flagged set, and conclude either that their data is a catastrophe or that the feature does not work. Neither is true. The function is doing exactly what a prediction interval does, and the number needs to be chosen deliberately per series based on how much volatility that series normally carries. Which raises the operational question the SQL does not answer: who picks 0.9999 versus 0.99999 for each of your tables, on what evidence, and who revisits it when the series changes character after a migration. A threshold is a promise about tolerance, and a promise made once by whoever wrote the query is a promise nobody maintains. This is the same trap as alert thresholds in infrastructure monitoring, except the cardinality is thousands of tables rather than dozens of hosts, so hand tuning does not scale even in principle.
Immutable models, forward only detection, and the operational shape nobody scopes
Three documented constraints combine into a design problem that only appears once you try to run this continuously. First, models cannot be updated in place. If the series changes, you create a new model, which means a schedule that creates model objects on a rolling basis and something to drop the old ones, or a schema that fills with dated artifacts. Second, models cannot be cloned, and cannot be shared across roles or accounts, nor replicated across accounts. If you build and validate in a development account and promote to production, you do not promote the model, you retrain it there, so the thing you tested is not the thing that runs. Third, and most limiting, anomalies can only be detected in test data, and every test timestamp must be greater than the training timestamps. Detection is strictly forward looking. You cannot point a freshly trained model at the last six months and ask what it would have caught, which removes the most natural way to validate a detector before trusting it, and removes the retrospective analysis you want in the days after an incident. Then there is throughput. Inference runs at roughly one second per 100 rows, and the documentation notes this is independent of warehouse size, so you cannot buy your way out of it. Scoring a million rows on that stated rate is on the order of ten thousand seconds, close to three hours, and sizing the warehouse up does not help. For a daily aggregate series with a few thousand points, none of this matters. For row level scoring across a warehouse, it decides the architecture: you monitor aggregated metrics per table rather than raw rows, which is precisely what a purpose built monitoring layer does by default and what you would end up building yourself.
The rule based half: data metric functions, and the ceilings worth knowing first
Snowflake data quality monitoring is the other native route, and it is closer to a monitoring product than the ML function is. System data metric functions live in the CORE schema of the shared SNOWFLAKE database and cover more ground than the usual summaries suggest. Accuracy metrics include NULL_COUNT and NULL_PERCENT, BLANK_COUNT and BLANK_PERCENT, ZERO_COUNT, NEGATIVE_COUNT, INVALID_JSON_COUNT, INVALID_NUMERIC_TYPE_CAST_COUNT, FUTURE_TIMESTAMP_COUNT, CASE_FORMAT_VIOLATION_COUNT, SPECIAL_CHARACTER_COUNT, and UNTRIMMED_STRING_COUNT, each with a percentage variant. Freshness has FRESHNESS and DATA_METRIC_SCHEDULED_TIME. Schema has SCHEMA_CHANGE_COUNT, which counts column additions, deletions, renames, and type modifications. Statistics cover AVG, MIN, MAX, MEDIAN, STDDEV, VARIANCE, the approximate quantiles at 25, 50, and 99, and string length aggregates. Uniqueness has DUPLICATE_COUNT, UNIQUE_COUNT, and ACCEPTED_VALUES, and volume has ROW_COUNT. Custom DMFs cover anything the system set does not. Four ceilings decide whether this scales to your situation. Enterprise Edition is required, which is a hard stop for teams on Standard. There is a limit of 50,000 total DMF associations on objects per account, generous until you multiply a handful of metrics by every column that matters across a mature warehouse. DMFs work on tables including temporary and transient ones, views, materialized views, dynamic tables, event tables, external tables, and Iceberg tables, but cannot be set on hybrid tables or streams. And the default schedule runs a DMF once every hour, which is either fine or far too slow depending on how quickly a bad number reaches a customer. Underneath all of it sits the authoring cost, which is the one that compounds. Every association is a decision made by a person who understood that column on the day they made it, and warehouses change faster than rule sets get revisited.
Choosing between building on the primitives and buying the layer above them
The honest version of this comparison starts by admitting the native tools are good. If you have five to ten important series, an engineer who enjoys this work, and no ambition to cover the whole warehouse, SNOWFLAKE.ML.ANOMALY_DETECTION plus a scheduled task is a sound choice and you should not pay anyone for it. Data metric functions on a few dozen critical tables are likewise reasonable, provided you are on Enterprise Edition and comfortable inside the association ceiling. The build versus buy line falls where coverage becomes the goal rather than a list of favorites. At that point you are no longer writing a detection query, you are operating a system: scheduling, a state store so repeat anomalies do not alert every run, per series thresholds someone maintains, a rolling retrain strategy because models are immutable, ownership mapping, routing into Slack or PagerDuty, acknowledgement and resolution, and monitoring of the monitoring so you notice when it silently stops. That work is not exotic, which is exactly why it gets underestimated. Teams ship version one in an afternoon and spend the next two quarters on the parts nobody scoped, usually funded by the most senior data engineer available and taken directly out of the pipeline work they were hired to do. Half of that person for a year costs a multiple of anything in this category, and that is the comparison worth putting in the business case. It is also why published pricing matters here more than in most software categories. Of the thirteen observability tools we track, only three publish a price: Soda at 750 dollars a month for its Team plan, Metaplane, and us. Monte Carlo publishes none. The Bigeye pricing page returns a 404. Datafold redirects its pricing page to a contact form. None of the major catalog and lineage vendors publish a price at all. Dataobservability is 99, 299, and 799 dollars a month, with a 14 day trial that needs no credit card, so you can hold a real number against the engineering estimate before anyone books a call.
Questions buyers ask
Snowflake anomaly detection FAQ
Does Snowflake have built in anomaly detection?
Yes. SNOWFLAKE.ML.ANOMALY_DETECTION is a schema level model object you create with CREATE and then score using its DETECT_ANOMALIES method. It trains a gradient boosting model on a timestamp column and a target column and flags rows falling outside a prediction interval. It is a detection function rather than a monitoring product, so scheduling, thresholds, deduplication, ownership, and alert routing are not included.
How do I detect anomalies in Snowflake?
Create a model with CREATE SNOWFLAKE.ML.ANOMALY_DETECTION over training data containing a timestamp column and a target column, setting LABEL_COLNAME to an empty string for unsupervised detection. Then call the DETECT_ANOMALIES method on that model against test data whose timestamps are all later than the training window. The result set includes FORECAST, LOWER_BOUND, UPPER_BOUND, and an IS_ANOMALY flag per row.
What is the default prediction_interval in Snowflake anomaly detection?
The default is 0.99, which flags anything outside the 99 percent prediction interval and therefore marks roughly one percent of rows as anomalous by construction. On a ten million row table that is around one hundred thousand flagged rows. Snowflake documentation recommends setting the value very close to 1.0, suggesting 0.9999 or closer, tuned per series rather than left at the default.
Can Snowflake detect anomalies in historical data?
No. The documentation is explicit that anomalies can only be detected in test data, not in the data used for training, and that every test timestamp must be greater than the training timestamps. Detection is strictly forward looking, so you cannot train a model today and ask what it would have caught last quarter. Retrospective analysis requires stored metric history from a monitoring layer.
Does Snowflake data quality monitoring require Enterprise Edition?
Yes. Snowflake documentation states that data quality monitoring with data metric functions requires Enterprise Edition. That applies to both system DMFs in the SNOWFLAKE.CORE schema and to custom DMFs you define. Teams on Standard Edition cannot use the native rule based route, which usually makes an external monitoring tool cheaper than an edition upgrade.
Can Snowflake data metric functions detect anomalies?
They detect rule breaks rather than statistical anomalies. A DMF returns a number, such as NULL_COUNT, DUPLICATE_COUNT, ROW_COUNT, FRESHNESS, or SCHEMA_CHANGE_COUNT, which you compare against an expectation you set. That catches a threshold being crossed, not a value that is merely unusual for a Tuesday. Statistical detection is the separate ML function, and the two are complementary rather than alternatives.
How many data metric functions can I attach in Snowflake?
Snowflake limits an account to 50,000 total associations of DMFs on objects. That covers every metric attached to every table, view, materialized view, dynamic table, event table, external table, and Iceberg table across the account. DMFs cannot be set on hybrid tables or streams, and the default schedule runs each DMF once every hour unless you change it.
How fast is Snowflake anomaly detection?
Inference runs at approximately one second per 100 rows, and Snowflake documents that this is independent of warehouse size, so a larger warehouse does not speed it up. On that stated rate, scoring a million rows takes on the order of ten thousand seconds. Training behaves differently: a standard XL warehouse handles roughly 100 series of 100,000 rows in about 211 seconds.
Can I tune the Snowflake anomaly detection algorithm?
Not meaningfully. The documentation states that you cannot choose or adjust the algorithm, and that trend, seasonality, and seasonal amplitude parameters cannot be overridden. Season length is tied to input frequency, using 24 for hourly data and 7 for daily. The controls you do have are prediction_interval, the choice between supervised and unsupervised training, and optional exogenous variables.
What is the best anomaly detection tool for Snowflake?
It depends on how many tables you intend to cover. For a small set of well understood series with an engineer to maintain them, the native ML function plus a scheduled task is genuinely sufficient. For rule checks on a few dozen tables on Enterprise Edition, data metric functions fit. Once coverage across the warehouse is the goal, a platform that learns baselines per table and routes to Slack or PagerDuty costs less than the engineering time it replaces.
More of the platform
Catch broken data before your stakeholders do
Connect your warehouse and get snowflake anomaly detection live from one read-only connection. Transparent pricing, no credit card.