In the SQL Rule Monitor creation flow, you can now select "Set threshold using: Value returned by query" along with the "Automatic" threshold type. MC will learn the rule's pattern and set automatic breach conditions. Our algorithm learns both trend information and daily & weekly seasonality, making this a good setting for metrics that grow predictably over time or have routine drops overnight / over weekends.

The checks are performed when executed with —-dry-run . It analyses the freshness_threshold defined and the expected threshold for the table. If something is wrong you will see messages like:

Warning - High breaching Freshness SLOs will be created, adjust freshness_threshold - analytics:prod.client_hub: freshness_threshold is 3, the expected minimum threshold is 462 - analytics:prod.client_warehouses: freshness_threshold is 3, the expected minimum threshold is 1410

I want my users to be Viewers of everything, but an Editor within their Domain." Previously, this was complicated to set up for your users, because you could not simultaneously include a user in the default 'Viewer' group and a custom Editor group just for their Domain. But now, this is possible!

Check that data coming from external partners is landing in your warehouse on-time, and in the size and quality that you expect. Read more about it here.

Query Change RCAs are now available for Freshness anomalies. This RCA correlates between changed/new write queries and freshness anomalies in a similar way we’ve been doing for volume anomalies. A notification on a Incident with a Freshness will be available when this RCA was detected.

Looking to easily update the Owner or Severity of an Incident without clicking into Incident IQ? You can now update it directly from the Incident card within the Incident Feed.

New filters on the Data Reliability Dashboard help you hone the metrics to just your most important data (Key Assets) or just specific Incident Types.

On the incident feed, two filters are added: the owners filters lets users filter for incidents assigned to specific users, and the severity filter lets users filter for incidents of certain severity levels.

We released a new way to ingest dbt artifacts with the following benefits:

• dbt run logs are now shown for dbt core integrations
• dbt core customers can supply a dbt job name in each run for MC to surface job name for any runs
• Fixed the bug where we sometimes mis-associate dbt errors to tables when the same dbt model exist in different schemas
• Fixed the bug where we sometimes skip generating certain dbt incidents when we couldn’t correctly map models to the right tables
• Fixed the bug where we incorrectly categorize dbt cloud integrations as core on the settings page

All changes are live for dbt cloud integrations. dbt core integrations will need to update CLI commands to get the updates (instructions here).

An improvement to the MC Incident Owner feature allowing for a user to assign themself through an easy to click button and to assign a MC recommended Incident Owner.