Automated freshness, volume, schema change monitoring are now available in beta for SQL Server. Please reach out to the MC team if you are interested in getting access.

For existing SQL Server connections, an extra permission GRANT VIEW SERVER STATE is needed for the MC service account users per docs here

Tags from dbt models (incl. meta configs) are now shown in dbt alerts!

Our lineage now shades all unmonitored tables gray. This can help highlight where you might have coverage gaps in your monitoring strategy.

Assets which are "lineage only" -- those that cannot be actively monitored, such as BI Reports -- will also show up with a white background.

To add monitoring coverage, a few options:

• Click on the unmonitored table node, and our recommendation engine might suggest the best way to monitor, such as with a Data Product
• Create a Data Product that includes the unmonitored table, and monitor that table
• Or go straight to our usage page, and add custom rules for monitoring configuration

We have added an option to create volume rules from the asset page!

• Our asset page now includes three widgets: Time since last update, Time since last row count change and Change in row count with their respective graphs.
• We've simplified the process of creating volume rules by enabling users to set manual thresholds through the two new widgets: Time since last row count change and Change in row count.
• We've improved the graphs related to these metrics.

More detail on these changes can be found at Volume monitor

We've said goodbye to the "Uptime" charts on the Data Reliability and Data Product Dashboards. We're working on something new instead, so let us know if you have needs around this type of reporting!

📘

Progressive rollout in the coming weeks

These changes will be rolled out to Workspaces in several phases over the coming weeks. Emails will be sent to all users in Account Owners, Domain Managers and Editors roles with additional details when these changes will take place in their Workspace and any necessary actions required.

New behavior for unmonitored tables

Custom monitors configured to run against unmonitored or muted tables will now fail with an "Error" status. This change ensures that monitoring is consistently applied to all relevant tables, improving the accuracy and effectiveness of your custom monitors.

New behavior for dbt alerts

dbt failures will only be raised as Monte Carlo Alerts if all tables associated with the dbt Model are enabled for monitoring in Monte Carlo. Learn more about dbt Failures As Monte Carlo Alerts

Enhanced user interface

When creating new monitors, unmonitored tables will be clearly identified in the table selection process. A modal will also be displayed when creating SQL monitors to highlight any unmonitored tables being referenced.

Viewing monitors with unmonitored tables

Prior to these changes being enabled in your Workspace, we recommend you address any monitors with Unmonitored or Muted tables.

To view Monitors with Unmonitored or Muted tables:

1. Navigate to Monitors

2. There will be a new column labeled "Unmonitored tables" or "Muted tables".

3. This provides a sortable column of the number of tables referenced by that monitor that are currently not monitored. We recommend you either enabled monitoring on these tables or disable the monitor if no longer in use. There are several ways to resolve this:

   1. If the monitor is no longer useful, disable or delete the monitor. This is done by going to the three dot menu under Actions and clicking "Disable" or "Delete"

   2. If the monitor is still useful and you want to ensure you continue to receive any alerts raised by the monitor, enable monitoring for the table(s) referenced by this monitor.

      1. Click into the monitor to verify what table(s) are "Not monitored" or "Muted".
      2. Navigate to the necessary tables to either enable monitoring on them or un-mute them. Refer to Recommended monitoring strategies for tables

This update reinforces our commitment to providing comprehensive monitoring capabilities and encourages users to enable monitoring for all relevant tables by either un-muting tables or enable monitoring for them through the Usage UI.

We heard clearly from our customers that not every alert/notification from MC is an "Incident." We also know that reporting and retrospectives on "alerts" is not always necessary, but these activities on true data incidents is critical to the success of data teams.

We're better aligning Monte Carlo to accepted industry tooling and terminology: triage alerts and escalate them to incidents where it makes sense, report on those incidents, and communicate them out to stakeholders if appropriate.

The past state of “Incidents” in Monte Carlo has been repurposed as “Alerts.” The use of “Severity” also split into “Priority” for Monitors and Alerts, and “Severity” will remain as the way to mark an Alert as an Incident.

• "Incidents" today become "Alerts" going forward.
• Custom Monitors can have a pre-set "Priority," replacing the pre-set "Severity" today.
• "Priority" from a Custom Monitor is inherited to an Alert, but is not changeable on the Alert.
• "Alerts" can be marked as "Incidents" by utilizing "Severity." This workflow will be further improved in the coming weeks.

More detail on these changes can be found at Introducing: Alerts.

We now have field lineage available for Databricks assets that are on Unity Catalog. To use this feature, make sure you have granted MC access to system table system.access.column_lineage. See details in docs here: https://docs.getmontecarlo.com/docs/overview-databricks#lineage

A beta version of the Motherduck integration is now available. Customers can run custom SQL monitors to observe data in Motherduck. See docs here https://docs.getmontecarlo.com/docs/motherduck

A new lineage experience is now available for all customers, which allows users to digest and navigate lineage more easily and intuitively.