Glossary
Public previewThe Analytics API is in public preview: on for every account, and features may change. Monitor run metrics are in private preview: reach out to your account representative to request access. See Integration and feature lifecycles for what this means.
Product words and the names the API uses for them.
Active monitor
A monitor that is not paused, deleted or a draft; its status is usually Enabled, Error, Snoozed, Training or Insufficient data.
In the product: there is no status called Active.
In the API: monitor__is_monitor_live.
Alert
An issue raised by a monitor, grouping one or more events.
In the product: Alert; what the product calls an Incident is an alert a user declared (see declared incident).
In the API: alerts keep their internal name, incident: the incident__ dimensions (incident__incident_uuid is one row per alert) and the incident_ metrics.
Alert status
Open (no status, acknowledged, work in progress) or resolved (fixed, expected, no action needed, false positive). Other older values count as open.
In the product: No status, Acknowledged, Work in progress, Fixed, Expected, No action needed; older alerts can also have False positive.
In the API: incident__incident_status; investigating is Acknowledged, empty is No status.
Alert type
What kind of check raised the alert, in two levels: Table, Metric, Validation, Job, Agent, then Freshness, Volume, Schema, Custom SQL, Validation and more.
In the product: the Alert type filter of the Alerts page, which also has a PII group.
In the API: incident_sub_type__incident_alert_type_group, incident_sub_type__incident_alert_type.
Anomaly
An alerted event that was not marked as normal, such as a value outside the learned or set threshold, a schema change or a job failure. Marking an anomaly as normal teaches the monitor that the value is expected.
Asset
A table, view or similar asset Monte Carlo discovered in a connected source, or an AI agent. MCON is its unique id. People say table for any warehouse asset, views included.
In the API: the asset__ dimensions; asset__asset_mcon is one row per asset and asset__asset_full_table_id names it; asset__asset_category = table is every warehouse asset (views included, AI agents not); asset__asset_type tells tables from views.
Asset tag
A key:value label on assets, set in Monte Carlo or imported from sources such as Snowflake or dbt.
In the API: asset_tag__asset_tag_name and asset_tag__asset_tag_value.
Audience
A named group of notification recipients (Slack channels, emails, PagerDuty and others) that monitors notify when they alert.
In the API: the audience__ dimensions; audience__audience_uuid is one row per audience.
Breach
A monitor run whose value broke the threshold condition (outside or inside a range, equal or not equal).
In the API: monitor_run_item__is_monitor_run_item_breach, monitor_run_item_breach_count.
Charge type
What consumed the credits (Table, Metric, Custom SQL, Validation, Comparison, Performance, the agents and others).
In the product: the Billing page.
In the API: consumption__consumption_charge_type.
Coverage
A monitored table is in scope of a Table Monitor; a covered table has at least one active monitor of any kind.
In the API: asset__is_asset_monitored, asset__is_asset_covered.
Credits
The unit Monte Carlo meters usage in under consumption pricing. Credits only, no dollar amounts.
In the API: consumed_credits.
Custom monitor
Any monitor a user creates other than a Table Monitor (metric, validation, custom SQL, comparison, job and agent monitors).
In the API: monitor__monitor_type other than table.
Data as of
The time the data on alerts, monitors and assets reflects, to the second: when it was last refreshed. Your own newest alert can be older. An alert created later is not counted yet, though a few rows refreshed at the same time can be minutes newer. The data is refreshed periodically, not in real time; credits and activity are refreshed on their own schedule, by day.
In the API: account__data_as_of.
Data product
The tables and reports a user added to it (its root assets, usually the most downstream ones behind a business outcome), plus the tables upstream of them in lineage. Deleted and excluded tables are left out.
In the product: lineage is walked for at most 30 hops and 2,500 nodes.
In the API: the data_product__ dimensions; data_product__data_product_uuid is one row per data product; the tables a user added have data_product_asset__is_data_product_root_asset.
Data quality dimension
Accuracy, Completeness, Consistency, Timeliness, Uniqueness or Validity, set on a monitor to say which quality risk it covers.
In the API: monitor__monitor_data_quality_dimension.
Incident (declared)
An alert a user marked as an incident and gave a severity, SEV-1 (most critical) to SEV-4.
In the product: Incident.
In the API: incident__is_incident_declared, incident__incident_user_severity.
Domain
A named set of assets used to scope access and reporting. Monitors and alerts are assigned to domains too.
In the product: the domain filter on the Monitors and Alerts pages uses the domain a monitor is assigned to, and also the domains of the assets for pipeline alerts (dbt and job errors) and merged alerts; the Coverage dashboard filters by the domains of the tables.
In the API: domain__ (the domains of tables) and monitor_domain__ (the domain a monitor is assigned to) dimensions; domain__domain_uuid and monitor_domain__domain_uuid are one row per domain.
Event
A single detection on an asset (anomaly, schema change, rule breach, job failure); one or more events make an alert.
In the API: the event_item__ dimensions (event_item__event_uuid is one row per event) and event_count.
Integration (warehouse)
A connected data source whose assets Monte Carlo monitors.
In the API: the warehouse__ dimensions; warehouse__warehouse_uuid is one row per warehouse.
Key asset
A table Monte Carlo's daily importance scoring marks as key, at the high end of the importance score.
In the product: called important tables ("Important tables without coverage"); a key asset flag set by hand is not reflected here.
In the API: asset__is_asset_important, asset__asset_importance_score.
Monitor
A check Monte Carlo runs on data or AI agents; it raises alerts when it finds a problem.
In the product: five categories: Table, Metric, Validation, Job and Agent.
In the API: the monitor__ dimensions; monitor__monitor_uuid is one row per monitor.
Monitor failed to run
The monitor itself could not execute (timeout, permissions, missing table). These are left out of alert counts and counted on their own.
In the product: the Error status on the Monitors page.
Monitor status
Whether a monitor runs, failed to run (Error, not that it alerted), is paused or still learning. Deleted monitors keep their last known status (often empty), so exclude them with monitor__is_monitor_deleted, not by status.
In the product: the Monitors page status filter: Enabled, Error, Disabled (paused), Snoozed, Training, Insufficient data, Draft.
In the API: monitor__monitor_status, in lowercase; the status on each day is monitor_status__monitor_status_value, for the last 35 days.
Monitor tag
A key:value label on monitors, often used for team ownership (for example team:finance).
In the API: the monitor_tag__ dimensions; monitor_tag__monitor_tag_uuid is one row per tag name and value.
Monitor types
Metric learns field statistics or custom metrics; Validation checks rows against conditions; Custom SQL checks the result of your own query; Comparison compares a metric between two sources.
In the product: Comparison is metric_comparison; Comparison - legacy is comparison.
In the API: monitor__monitor_type.
Multi-table monitor
One monitor definition applied to many tables; Monte Carlo creates one child monitor per table, or per variable value for SQL rules. Monitor counts include it once, not once per child.
In the API: monitor__is_monitor_parent, monitor__is_monitor_child.
Priority
P1 (highest) to P5, the monitor's default for its alerts; an alert merged from several takes the highest.
In the product: No priority when not set.
In the API: monitor__monitor_priority.
Status update rate
The share of alerts that got a status.
Table Monitor
Watches a set of tables for freshness, volume and schema changes, with thresholds learned automatically from metadata.
In the product: Table Monitor; older material calls it out-of-the-box or automatic monitoring.
In the API: monitor__monitor_type = table.
Time
Every metric has its own date, such as when an alert was created, when an event was detected or the day credits were consumed. Days, weeks and months are in UTC. Weeks start on Monday; months, quarters and years are calendar ones. "This month" or "this quarter" runs from its first day through today; "last month" or "last quarter" is the previous full one; "the last N days" is today and the N days before it, a filter on or after the date N days ago. A quarter is never 90 days.
In the API: metric_time at a grain: metric_time__day, metric_time__week, metric_time__month, metric_time__quarter, metric_time__year.
Time to fixed
Hours from alert creation to the Fixed status; also called time to resolution (TTR). Only alerts whose first or latest status is Fixed have it.
In the API: incident_average_ttr_hours, incident_median_ttr_hours.
Time to response
Hours from alert creation to its first status, of any kind.
In the product: the Time to response card (Activity) and Time to response (alerts) card (Data operations) count only Acknowledged, Expected and No action needed, else the latest status, so their numbers differ.
In the API: incident_average_first_feedback_hours, incident_median_first_feedback_hours.
Uptime or SLA
Monte Carlo has no uptime or SLA measure. The nearest are asset health (the share of tables without a data quality alert) and time to fixed.
In the API: asset_health_score_7d, incident_median_ttr_hours.
Users and page views
People active in the Monte Carlo app and the pages they viewed.
In the product: the Activity dashboard.
In the API: user_count, active_user_count, user_page_view_count.
Updated about 1 hour ago
