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.


By Sept 15, 2025

Comparison Monitors Migration (v2)

We're upgrading comparison monitors to a new version for improved reliability and performance of runs, more consistent schema handling across warehouses, better parity between UI and Monitors‑as‑Code (MaC) features, and clearer run history and auditability during future changes.

What's changing

  • You may notice a short suffix added to new monitor names to ensure uniqueness.
  • For UI comparison monitors:
    • Your existing v1 comparison monitors will be disabled and kept for run history.
    • A new replacement monitor will be created and is expected to run without issues.
    • After 30 days, we will delete the old v1 monitors (their run history remains available until deletion).
  • For MaC comparison monitors:
    • We will create new versions as UI monitors first.
    • We'll provide files that list the new monitor UUIDs, grouped by namespace, so you can convert them back to MaC.

Timeline

  • Migration begins shortly; no action is needed for UI-only users.
  • Old v1 monitors will be deleted 30 days after migration.

What to expect in the UI

  • You'll see a new comparison monitor replacing the old one. The old one will be disabled and retained for history until it's deleted.
  • The new monitor should run normally; no configuration is required from you.

For MaC users: Converting migrated monitors back to MaC

We'll share per-namespace files containing the UUIDs of your new (UI) monitors. To convert:

  1. Convert UI monitors to MaC for a namespace:
  • Command:
montecarlo monitors convert-to-mac --namespace <namespace> --project-dir ./tmp --monitors-file <file with uuids>
  • This creates MaC resources under the specified namespace in ./tmp, but does not update your original template automatically.
  1. Update your template file:
  • Open the generated content and copy the section beginning with:
  metric_comparison:
  • Append that section to the end of your original template under the same namespace.
  1. Apply:
  • Run your usual apply:
montecarlo monitors apply
  • You'll see the new monitor names marked as UPDATED as the template syncing occurs.

Notes:

  • Names may include a short suffix to ensure uniqueness in templates.
  • If you manage multiple namespaces, repeat the steps per namespace with the corresponding UUID file.

Do I need to do anything?

  • UI-only users: No action required.
  • MaC users: Follow the conversion steps above after we provide the UUID files, and then update/apply your templates.

If you have questions or run into any issues, please reach out and include the namespace(s) you're working with.

Updated 9 days ago