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

You can now filter by Audiences on the Incidents feed, to quickly get to the list of alerts that match your notification channels.

With the v0.90.0 release of the CLI (scheduled for May 24, 2024), Python 3.7 will no longer be supported due to the the version EOL. You can continue to use Python 3.7 on older versions of the CLI, but going forward, Python 3.8 will be the minimum required version.

Note that, as part of this release, support for Python 3.12 was also added!

For dbt test failures and warnings, we now added in the incident details view
i) the compiled SQL code,
ii) the ability to run that SQL and return the rows,
iii) the ability to edit those queries for ad hoc investigations.

Metric monitors now allow users to define a custom metric using SQL. This allows users to create a metric that:

• Isn't available off the shelf, such asAPPROX_PERCENTILE(order_amount, 0.99)
• References multiple fields at once, such asAVG(price + tax_collected)

Currently, only manual thresholds are supported for custom metrics. See our docs to learn more.

Duplicate (count) is now available within Metric monitors. This metric is a useful alternative to the Unique (%)metric, particularly if you are looking to ensure a column is always 100% unique. On large tables, a small number of duplicates can cause 100% unique to become 99.99999% unique. Which can be hard to visualize in charts and can sometimes be rounded off.

Duplicate (count) is a much easier way to visualize uniqueness. Since if a duplicate emerges, it goes from 0 to 1 instead of 100% to 99.99999% unique.

Duplicate (count) is calculated as the difference between the total number of rows with non-null values and total number of distinct non-null values.

Check out our full list of available metrics.

Automated freshness and volume monitoring are now available for SAP HANA. See docs for more details.

We have revamped the account onboarding to streamline getting started with data observability for your organization. Think of it as a fresh coat of paint, but the engine got a big tune up too.

Monte Carlo has identified an issue with custom monitors that use Dynamic schedules on VIEW table types. Currently, Dynamic schedules require freshness information to function correctly, which isn't available for VIEW tables.

As a result, these monitors have defaulted to running every 48 hours. To ensure consistent monitoring and to avoid future issues, we will automatically update all affected monitors to fixed schedules with a 48-hour interval starting yesterday, April 24th. Additionally, we will implement a new validation rule to prevent Dynamic schedules from being applied to VIEW tables.

• If you NOT are using MaC: No action is needed unless you wish to adjust the frequency of your monitor schedules to shorter than 48 hours.
• If you are using MaC: Starting yesterday, April 24th, you will be unable to edit these monitors through MaC without switching to a fixed schedule due to the new validation rule. If you attempt to apply without having changed any of these monitors, it will still work! However, once one of these monitors are edited, if the schedule is not also modified, the apply will throw an error. We recommend updating your monitors to fixed schedules to avoid disruption.

If you have any questions about this change or would like a list of monitors impacted by this change for your account, please reach out to our support team at [email protected].

This can be used in situations like “Alert if the mean of sale_price is not between 500 and 1,000.”

The behavior here is not inclusive, meaning the above example could also be read as “Alert me if the mean of sale_price is <500 or >1000.”