Guides
ChangelogStatus PageAPI ExplorerAPI ReferenceCLI ReferenceBlogIMPACT 2025
Start typing to search…

Changes to legacy monitors

There are several old types of monitors that can no longer be created, because their functionality has been consolidated into the current set of monitors. Below is a list of planned changes to their functionality and/or UI, to ensure customers are benefiting from a consistent, reliable, and up to date experience.

By March 1, 2025

  • Users will no longer be able to use the field_health property in Monitors as Code to create new monitors. Instead, use the metric property, to benefit from improved anomaly detection and alert UI. Existing monitors will continue to function without interruption.
  • Users will no longer be able to use the createOrUpdateMonitor mutation to create a Metric monitor via the API/CLI. Customers should use createOrUpdateMetricMonitor mutation instead, to benefit from improved anomaly detection and alert UI. Existing monitors will continue to function without interruption.

By May 1, 2025

  • Metrics - legacy monitors will instead appear as Custom SQL monitors in the UI. The monitors will continue to function without interruption. The substance of the notifications should remain the same, but the exact format will change to that of Custom SQL monitors.
  • Dimension Tracking monitors will instead appear as Metric monitors in the UI, using the Relative Row Count metric. The monitors will continue to function without interruption. Users will benefit from improved anomaly detection and better UI, such as having thresholds visible in the charts.

By Aug 10, 2025

Field Quality Rules → Custom SQL Monitors

On August 10th, we will be automatically migrating all existing Field Quality Rules to Custom SQL monitors. This migration is part of our ongoing effort to consolidate and improve our monitoring capabilities. If you have any questions or concerns please don’t hesitate to contact our support team.

What This Means for Your Monitors

Monitor Behavior After Migration

  • Your Field Quality Rules will appear as Custom SQL monitors in the UI
  • All monitors will continue to function exactly as before - same schedules, thresholds, and alert conditions
  • The underlying SQL queries that power your monitors remain unchanged
  • All historical data, incidents, and trends are preserved
  • Your existing notification settings and audiences remain intact
  • Monitor type will show as "Custom SQL" instead of "Metric - legacy"
  • The monitor configuration will display the underlying SQL query that was previously auto-generated
  • All other monitor details (schedule, thresholds, descriptions) remain the same

Monitors as Code

What Happens to Your YAML Files

Your existing monitors-as-code YAML files will continue to work after migration, but:

  • Field Quality Rules in your YAML files cannot be edited after migration
  • You'll receive warnings when applying templates containing Field Quality Rules
  • No new Field Quality Rules can be created via monitors-as-code
  • Starting on October 31st, all YAML files referencing field_quality definitions will start getting rejected, and will need to be updated to the new definitions.

Migration Path for Monitors as Code

To update your monitors-as-code configuration after migration:

Option 1: Export via Monte Carlo CLI

  1. Export all migrated monitors to YAML
# Export all your monitors to get the new Custom SQL format
montecarlo monitors export-as-latests --namespace <your namespace>

Option 2: Export via Monte Carlo UI

  1. Navigate to your Monitor detail page
  2. Click View YAML

Updating Your Configuration

  1. Replace Field Quality Rules sections (field_quality) in your YAML with the exported Custom SQL monitors
  2. Apply the updated configuration

Example Migration

Before (Field Quality Rule):

field_quality:
  - name: "Null Check on Customer Email"
    tables:
      - "customers"
    fields:
      - "email"
    metric_type: NULL_RATE
    alert_conditions:
      - operator: GT
        threshold: 0.05

After (Custom SQL Monitor):

custom_sql:
  - name: "Null Check on Customer Email"
    sql: |
      SELECT
        (COUNT(*) - COUNT(email)) * 1.0 / COUNT(*) as null_rate
      FROM customers
    alert_conditions:
      - operator: GT
        threshold: 0.05

Recommended Action

  1. Export your migrated monitors using CLI or UI
  2. Update your YAML configuration files
  3. Deploy updated configuration

Warehouses with Sampling Disabled

Monitor Execution

If your warehouse has data sampling disabled:

  • Migrated monitors will continue to work - Monte Carlo has special handling to ensure migrated Field Quality Rules execute properly even with sampling disabled
  • Monitor results and alerting function normally
  • No action required from your side

Copying/Cloning Monitors

When you copy or clone a migrated monitor:

  • The copied monitor retains the ability to execute with sampling disabled
  • Internal tracking information is preserved to maintain functionality
  • Copied monitors work identically to the original migrated monitors

Editing Restrictions

Important: If your warehouse has sampling disabled, you cannot edit migrated Field Quality Rules through the UI or API. If you attempt to do so, an error will be displayed indicating your warehouse does not support value based thresholds.

Recommended approach: Use Metric monitors instead, which are designed to work optimally with sampling disabled.

Updated 25 days ago