Over the coming weeks, we’ll release major changes to how users interact with alerts from Metric and Custom SQL Monitors. This is a follow-on to similar capabilities we released for Freshness & Volume back in February.

After this release, when users receive a Metric or Custom SQL alert:

  • The anomaly is automatically excluded from the set of data that trains the models. This means thresholds don’t automatically widen after an alert.
  • Users can ‘mark as normal’ if they’d like to re-introduce the anomaly into the set of training data. This widens the threshold.
  • Users can ‘select training data’ to exclude periods of the monitors history that they don’t want to models to learn from. This typically narrows the threshold.

These changes gave users dramatically more control of their thresholds when we released them for freshness and volume, and we’re excited to do the same for Metrics and Custom SQL. Because it helps to keep thresholds tighter, it also has the effect of leading to more alerts.

Note that these replace the Fixed alert status influencing the anomaly detection. With this change, alert status will be completely decoupled from tuning the anomaly detection. See our docs for more detail.


Click "Mark as normal" on a Metric or Custom SQL alert to re-introduce that data point to the set of data that trains models. This will widen the threshold.

Click "Mark as normal" on a Metric or Custom SQL alert to re-introduce that data point to the set of data that trains models. This will widen the threshold.


Click "Select training data" to select periods of the monitor's history to exclude from training the models. This typically narrows the threshold.

Click "Select training data" to select periods of the monitor's history to exclude from training the models. This typically narrows the threshold.

Monte Carlo released an Azure Devops Repos Integration, which allows customers to evaluate code impact on data. Users can see pull requests from Azure Repos overlaid on incident charts as well as displayed on a table's assets page, which help users assess the impact of such pull requests on their data. See details and instructions in docs https://docs.getmontecarlo.com/docs/azure-devops

Over the past few days, we released a few changes to data products:

  • Health tab is replaced with Data Operations. The Health tab was outdated and its metrics were inconsistent with the most popular Data Operations Dashboard. The new Data Product > Data Operations tab is an embedding of the Data Operations dashboard. If you’d like to further filter/edit/save the dashboard, there’s a path to click out into Dashboards > Data Operations to do so.
  • Simpler creation flow. The experience to create a Data Product is now one page instead of two, and more closely mimics the experience of creating a monitor.
  • Coming soon: optimizations to Data Product lineage. We’ll default to the ‘Table’ view instead of the lineage view, and release some changes to improve loading times for big lineage graphs.

Data Operations section within a Data Product. Click on the ... in the top right to open the view directly in the Data Operations Dashboard, which allows further filtering, customization, and saving.

We’re releasing a dramatic set of improvements to anomaly detection in Custom SQL Monitors. This will be released to the customer base in waves, starting tomorrow. It will be generally available to all customers in about 2 weeks.

Specifically, we’re taking many of the improvements we made to Metric monitors last year, and applying them to Custom SQL monitors that are configured to use automatic thresholds. Those monitors will see:

  • Significantly tighter thresholds
  • Support for “seasonal” patterns (day-over-day, week-over-week)
  • Faster training of thresholds

We expect this to increase the number of alerts generated by Custom SQL monitors with automatic thresholds. If it becomes too noisy, we suggest users adjust the sensitivity of the monitor.


This week, we released two new options for how to apply Table Monitors from Settings. These additions provide more flexibility to select the desired tables. Specifically, we’ve added:

  • Include all tables in a Domain: This is useful if you want to apply table monitors to all tables in a given domain.
  • Exclude all tables in a warehouse, database, or schema: This is useful to include all tables in a warehouse or database, but exclude certain databases or schemas therein.

Dynamic schedules (When a table is updated) are now available for Metric, Validation, Comparison, and Custom SQL monitors. This scheduling option allows you to reduce time to detect data quality issues by running monitors shortly after the underlying table is updated.

We’re excited to share that we are evolving our legacy “insights” reports into a new, richer Data Exports product.

Originally launched as an experimental way to surface metadata insights, the legacy insights reports have grown misaligned with how our customers think about and interact with Monte Carlo. Over time, customers have shared that the current insights are difficult to use, hard to map to their mental model of Monte Carlo, and are missing key fields.

That’s why we’re transitioning to a new data exports that:

  • Makes critical Monte Carlo objects—Monitors, Alerts, and Assets—exportable in clean, consistent formats
  • Simplified and reliable exports that mirror what you see in Monte Carlo
  • Accessible to download directly from the relevant pages in the UI

See more information in our data exports documentation.

Migration from Legacy Insights

We're sunsetting the legacy insights. Here's what to expect:

  • The Insights tab will be removed from the UI
  • The “Monitored Tables” insight has been moved to Settings → Table monitors
  • Full deprecation will be July 1, 2025. If you have concerns about losing specific insight reports, please reach out to your customer success manager or [email protected]

We've updated the audience creation form to simplify the experience of configuring recipient channels and managing monitor notifications.

Previously, new users in Monte Carlo would land on the Alerts page. This change only affects go-forward new users. If your first login was earlier than today, you will continue to land on Alerts.

User research indicated that the majority of new users were seeking for information relating to their table, i.e. check lineage, see freshness or volume, add a monitor, etc. Landing on the alerts page often made it tricky to fulfill that intent, because it was hard to search & open for the specific table you cared about.

You can now acknowledge and resolve alerts, mark them as incidents, assign owners, and snooze monitors without leaving Teams or the Monte Carlo alert feed. With direct links to add Jira issues and view monitor details, you can get data operations work done quickly.


The feed is gradually rolling out to customers and Microsoft Teams will be released to all on Monday. If you would like it turned on now, please reach out to [email protected].