A few months ago, we introduced Mark as normal so users would have greater control over the automated thresholds in Monte Carlo. This function lets users indicate if an anomaly is ‘normal’ behavior or not. If it is marked as normal, then Monte Carlo will not alert to similar anomalies on that table in the future.

But if you had an alert affecting many tables, and you wished to mark them all as normal, this involved a lot of clicking. Users would need to go through them one by one.

With this release, users can now easily mark all the anomalies in an alert as normal, without needing to click through them all one-by-one. To do so, first click the 'Tune model' dropdown in an alert, then 'Mark as normal'. This will open a modal with the option to mark all as normal, or just that specific event.

Our integration with Collibra is now available in public preview! It enables customers to integrate data and AI observability directly into their data catalog. This helps teams manage trust at scale, communicate incidents clearly, and track the health of data assets directly where stakeholders already work.

Learn more in the Collibra documentation.

We've made some tweaks to our Volume anomaly detection, making it slightly less sensitive. Users should expect Volume thresholds to widen slightly, with the effect of roughly ~20% fewer Volume alerts.

A few months ago, we rebuilt our Volume anomaly detection, making it dramatically more sensitive. These changes nearly tripled the number of Volume alerts that Monte Carlo sends. The overall reception to these changes has been great, but we've found the default 'Medium' sensitivity to be sending more alerts than is universally desirable. As a result, we've implemented these changes to make it slightly less sensitive.

Users can still benefit from our most sensitive anomaly detection by setting Sensitivity to High.

We've redesigned and rebuilt comparison monitors with a focus on usability. The new experience supports:

• Monitor creation without writing SQL
• Comparing multiple metrics in a single monitor
• Cloning monitors and changing table selection while preserving alert conditions
• Automatic runs when target tables or data sources are updated
• Simpler debugging with visibility into which warehouse triggered an error
• Increased limit from 100 to 500 field/metric/segments tracked
• Clearer results, alerts, and notifications

The Asset Editor and Asset Viewer user roles are no longer available. These roles only had access to the Assets page in Monte Carlo. They were introduced a few years ago for customers who were using Monte Carlo as a data catalog. However, users have generally struggled to see value when assigned these roles, so ultimately we have chosen to deprecate them.

Configurations (users, authorization groups, single sign-on defaults, etc) that already have these roles selected will not be impacted. They can keep the Asset Editor and Asset Viewer role.

Read more about our user roles.

Users can now discover and investigate ETL job performance issues natively in MC via the Job Performance Dashboard. Airflow DAGs, dbt jobs, Databricks workflows, Azure Data Factory pipelines are supported. See docs here.

You can now triage alerts with your team in Google Chat by configuring it as an audience recipient channel.

Over the next two weeks, all Dimension Tracking monitors will be switched over to Metric Monitors that use the Relative row count metric. No interruption to service or monitoring coverage is expected. You can read more about the Relative row count metric in our documentation.

The change is part of a broader effort over the last several months to clean up old monitor types. This helps to streamline reporting, filtering, and overall usability across Monte Carlo.

This change has been communicated to affected accounts over email during the last several weeks.

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.

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