Consumption Rates

Monitors

Monitors alert the user when a set of conditions (defined by a Customer or by Monte Carlo) about their data, metadata, or infrastructure are met.

Monitors consume Credits on a daily basis using the Consumption Rates defined below. There are four different categories of Monitors (Table, Metric, Validation, Query Performance), and each category can contain multiple Monitor types.

The Consumption Rate of a Monitor is measured once per day. Credits are not consumed if the Monitor is in a Disabled status at the time the measurement. Credits will be consumed for all other Monitor statuses, and the type and frequency of the monitor's schedule does not affect its Consumption Rate.

Table Monitors

Table Monitors are used to detect delays and breakages in data pipelines. They are broadly applied across pipelines or data products, and ensure that tables have updated at the right time, that the right amount of data was flowing in, and in a consistent schema.

One Table Monitor includes all of the following for one table or view:

• Freshness, as measured by time since last update and/or time since last row count change
• Volume
• Schema Change

Byte count is sometimes used for freshness and volume, if row count is not available.

The Consumption Rate is measured per warehouse, based on the count of tables or views with a Table Monitor applied.

Metric Monitors

Metric Monitors are used to detect anomalies in statistical or business metrics, or reconcile those metrics across different warehouses.

Included Monitor types: Metric, Comparison

The Consumption Rate is measured per Monitor, based on the count of metrics tracked by that Monitor. The count of metrics is calculated as the number of field-metric pairs, multiplied by the number of segments. The count of segments is measured using the number of distinct segments collected in the second-most-recent run of the monitor. A value of "1" will be used for the count of segments in the event no segments were collected.

Some examples:

• a Metric Monitor tracking the Null (%) for 1 field counts as 1 metric
• a Metric Monitor tracking the Null (%) for 2 fields and 20 segments counts as 40 metrics (2 x 20)

Most Metric Monitors that get created are simple. Across the customer base, the median Metric Monitor tracks 1 metric (1 credit/day). Only 5% of Metric Monitors are tracking more than 100 metrics, and only 1% track more than 1,000 metrics. However, when needed, a Metric Monitor can be scaled to track many thousands of metrics. In unusual cases, Metric Monitors can be scaled to track up to 1 million metrics. To see an extended Consumption Rate scale up to that limit, click here.

Users can also create multi-table Metric Monitors. These consume credits at the same rate as if each table had a standalone Metric Monitor. In other words, if you seek to track 3 metrics across 10 tables, it will consume the same number of Credits regardless of you used one multi-table monitor, or 10 monitors each monitoring a distinct table.

For Comparison Monitors, the number of metrics is counted in the source and target respectively, and then summed to get a total number of metrics for billing. The number of segments in the source vs target can vary, so the number of metrics in source vs target can be different.

Validation Monitors

Validation Monitors are used to identify bad individual rows and check specific business logic.

Included Monitor types: Custom SQL, Validations

The Consumption Rate is measured per Monitor, based on the count of variations tracked by that Monitor. For Custom SQL, variations are counted as the unique combinations of all SQL Variables included in the Monitor. Validations do not yet support variations, so total variations in the Monitor is always 1 until that capability is introduced.

Some examples:

• a Custom SQL Monitor with no variables counts as 1 variation
• a Custom SQL Monitor with two variables, each with 5 values, counts as 25 variations (5 x 5)

Query Performance Monitors

Query Performance Monitors are used to identify slow, inefficient queries that are spiking your warehouse spend, or that might eventually time out and cause a data quality issue.

The Consumption Rate for Query Performance Monitors is a flat rate of 20 Credits per day, per Monitor.

Additional Monitor Types

Some additional Monitor types exist, with the following Consumption Rates:

• JSON Schema: 2 Credits per Monitor, per day
• Freshness Rules: 2 Credits per table included in the Monitor, per day
• Volume Rules: 2 Credits per table included in the Monitor, per day
• Metric - legacy: this Monitor type is deprecated but still operates for customers who configured them in the past. The Consumption Rate is the same rate as a Metric Monitor.

Agents

Troubleshooting Agent

Beginning April 1, 2026, Troubleshooting Agent will begin consuming Credits for usage above the threshold described below.

Troubleshooting Agent automates the process of finding the root cause of a data issue, by sifting through context (changes in data, system issues, code changes, lineage, etc) and iterating through different hypotheses.

Consumption is based on the number of Alerts that Troubleshooting Agent is used on (“Investigations”). In a given month:

• The first 3 Investigations are free (no Credits are consumed)
• Above that, 2,000 Credits will be consumed per 20 Investigations.
• By way of example, whether you use 5 or 20 Investigations in a given month, 2,000 Credits will be consumed for that month.
• Remaining investigations do not roll over to the next month.

Metering is on the account level, not per user. Running Troubleshooting Agent multiple times on the same alert only counts as 1 Investigation. Use the Alerts Data Export to understand on which Alerts the Troubleshooting Agent has been run.

Agent Observability

Beginning May 1, 2026, Agent Observability will begin consuming Credits using the Consumption Rates defined below.

Agent Observability gives you full visibility into your AI agents, from the data that powers them to the prompts they receive and the outputs they generate.

Consumption is based on the number of Agents for which Monte Carlo is observing traces, as well as the number of Agent Monitors on those Agents.

By way of example:

• An account with 4 Agents and 75 Agent Monitors is a Medium
• An account with 25 Agents and 50 Agent Monitors is a Large

The types of Agent Monitors are listed here. The number of Agent Monitors is measured once per day, and does not include any Agent Monitors with a Disabled status. The frequency of the monitor's schedule does not affect its Consumption Rate.

The count of Agents is based on the number of distinct agent names. In cases where tracing is set up through instrumentation with Monte Carlo's SDK, the name is defined there. In cases where the Agent is built through an agent platform like Snowflake Intelligence, the name of the Agent is inherited from the platform.