Monte Carlo makes it easy to instantly deploy broad monitoring of your data pipelines, without manually configuring any thresholds. It learns the normal patterns of updates, size changes, and size growth, and alerts when those patterns are violated. This is ideal for detecting breakages and stoppages in the flow of data.

For regularly updated tables, Monte Carlo can typically generate thresholds after 7 days of observing a table, and thresholds will be mature by 14 days. At most, monitors will incorporate a 6-week rolling window of training data to determine thresholds, including handling of weekly seasonality.

The sensitivity of thresholds can be adjusted between High, Medium, and Low. Users may also choose a manual threshold, instead of relying on thresholds generated by machine learning. Learn more about sensitivity settings.

In most cases, Table Monitors use metadata instead of directly querying the table. Coverage includes:

• Freshness: alerts to unusually long periods of time between updates or changes in size (row count or bytes)
• Volume: alerts to unusual changes in size
• Schema change: alerts to changes in the schema of the table (no machine learning involved here)

Creating Table Monitors

Table monitors can be created from the Create Monitor page or Assets page. Configuration steps include:

Choose tables

Table monitors are designed to be applied to pipelines, schemas, or data products, in order to alert to broad outages and breakages.

If you have access to more than one Domain, assign the monitor to a Domain. If you were already working in a Domain when you created the monitor, that Domain is selected for you — change it here if you want the monitor to cover a different one.

Then choose a warehouse. You can select the entire warehouse, or specific databases or schemas within it.

Refine with filters

Users can then narrow your selections further by adding inclusion or exclusion filters on:

• Table name — Operators include: starts with, ends with, contains, matches pattern.
• Table tags — Operators include: is one of, has all.
  • Covers tags you apply yourself as well as the Data Product tags Monte Carlo applies automatically, so you can filter to a whole Data Product here.
• Table type — for example, to exclude Views.
• Read activity, Write activity, or Read or/and write activity — for example, only assets queried in the past 14 days.
• Row count change — for example, only assets whose row count changed in the past 31 days.

Combine filters

Filters can be joined with AND or OR. The include list and the exclude list each have their own setting:

• OR (default) — a table matches if it meets any filter in the list.
• AND — a table matches only if it meets every filter in the list.

Use AND across different attributes — for example, one filter row for Data Product tags and a second row for a custom asset tag (i.e, team:finance).

Note: When using AND, make sure your filters don't cancel each other out. Two filters on the same attribute usually can't both be true for a single table — for example, "Table name starts with stg" AND "Table name starts with dev" should use an OR instead.

Preview

A preview of matching assets appears at the bottom of this section.

Coverage stays current

The list of matching tables is re-evaluated on every monitor run. New tables that meet your criteria are picked up automatically, and tables that no longer meet your criteria are removed automatically — you don't need to edit the monitor.

Alert conditions

When creating a Table Monitor, users can choose to be alerted when:

• Time since last update is anomalous
• Change in row count is anomalous
• Time since last row count change is anomalous
• Schema is changed
  • Fields added
  • Fields removed
  • Field types changed

By default, table monitors use automated thresholds based on machine learning that do not need to be defined by a user. To change sensitivity across the Table Monitor, see Automatic threshold sensitivity below. To set a manual threshold, disable alerting, or change sensitivity for a specific metric on a specific asset, go to the Asset page, click the more options (⋮) menu on the chart for that metric, then select Edit monitor.

Row count collection

Whenever possible, Table Monitors use metadata to minimize the workload on your warehouse. However, some asset types (such as Views) and certain integrations don't expose row count metadata. For these assets, you can enable row count collection, which runs a COUNT(*) query to collect row counts directly and enable Volume and Freshness (Time since last row count change) monitoring. Some platforms provide volume tracking through byte count metadata — on these platforms, row count collection is an optional addition to add row-level granularity.

Enabling row count monitoring

To enable row count monitoring, row count collection must be enabled. This can be enabled in one of two ways:

• At the Table Monitor level, which applies to all qualifying assets in the monitor's scope — including any that match in the future. Set this in the UI or, for via Monitors as Code
• At the asset level, where you can also apply a WHERE clause filter to the COUNT(*) query — useful for large tables where filtering to recent partitions or active segments can significantly reduce query cost and improve performance. Set this on the asset’s summary page via Enable row count monitoring, or via the toggleSizeCollection API.

Asset-level settings always take precedence over the Table Monitor setting. If row count collection is explicitly disabled on an asset, the Table Monitor will not override it. If an asset is covered by multiple Table Monitors, row count collection is enabled if any of them has it turned on.

Automatic threshold sensitivity

Sensitivity is a threshold tuning option that controls how readily monitors alert on anomalies. Users can optionally change sensitivity at the Table Monitor level to:

• Low
• Medium (this is the default option)
• High

The selected sensitivity applies to any of the alert conditions enabled in the Table Monitor (Volume, Freshness, and/or Time since last row count change) across every in-scope asset, including assets that come into scope later.

For granular control, sensitivity can be changed at the asset-level, which overrides the Table Monitor setting. If an asset is covered by multiple Table Monitors with conflicting settings, the lowest sensitivity wins. All sensitivity changes are captured in the monitor change log, including the source (user or Table Monitor) and from/to values.

Learn more about sensitivity settings.

Define schedule

By default, table monitors run hourly. This default cannot be changed when using automated thresholds. However, the schedule can be customized when using manual thresholds. This can be done on the Asset page by clicking Tune Model, then Edit Monitor on the chart for that metric, then switching to Explicit threshold.

Send notifications

Select which audiences should receive notifications when anomalies are detected.

Advanced settings exist for managing failure notifications.

Add details

Assign the monitor a:

• Title (required). This will be inherited as the name of alerts generated by the monitor.
• Priority (optional). This will be inherited as the priority of alerts generated by the monitor.

Table Monitors can also be created or updated programmatically via the createOrUpdateTableMonitor API operation.

Domains

Each Table Monitor is assigned to a single domain. That assignment controls who can see and edit the monitor, independent of which tables end up in scope.

• Visibility: A monitor assigned to a domain is visible to users with access to that domain, and to users without domain restrictions.
• Unassigned monitors: A monitor created prior to this requirement, with no domain association ("All Domains"), is visible only to users without domain restrictions — even if the tables it covers belong to a restricted user's domain.
• Scope vs. assignment: Filter criteria can match tables belonging to several domains. The monitor's domain assignment governs access; the tables in scope do not.
• Reference domains: Reference domains affect which tables a metric monitor may be created over — they do not change which tables a Table Monitor's filters match.

Overlapping coverage

When a table is covered by multiple Table Monitors that share the same alert condition, each monitor will generate a separate alert for the same anomaly. The sections below cover best practices for scoping monitors to minimize overlap.

Monitoring with Domains and Data Products

It’s important to understand how Table Monitors relate to Domains and Data Products. This will help you set up alerting in a way that aligns with team ownership while minimizing maintenance overhead.

Principles

• Domains represent teams. They own and manage their own monitoring and alerting.
• Data Products represent tables that are critical to stakeholders.
• Each team should manage its own monitors. If another team depends on a Data Product, they should request the owning team to monitor it.

Best Practices for Monitoring Data Products

1. One Table Monitor per domain per warehouse

   • This keeps monitoring centralized and avoids alert duplication.
   • The Table Monitor is automatically scoped to the team’s domain during creation

2. Add new Data Products to the existing Table Monitor

   • When a new Data Product is created, the owning team can add it to their Table Monitor.
   • This ensures consistent coverage without proliferating monitors.

3. Choose the right construct for monitoring

   • Data Products are powerful for modeling business use cases (e.g., financial reporting).
   • For upstream or ingestion teams schemas may be a better fit for scoping Table Monitors.
   • The key is to align monitoring with team ownership and what matters most.

Example

• A Finance domain creates a Table Monitor scoped to its warehouse and adds all Data Products tied to reporting.
• An Ingestion domain instead creates Table Monitors at the schema level, since their ownership is tied to source data pipelines rather than specific Data Products.