Glossary

ℹ️

Private preview

Composable dashboards and the metrics API are in private preview: available to invited accounts, and features may change. See Integration and feature lifecycles for what this means, and reach out to your account representative to request access.

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: incident, the incident__ dimensions 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: asset; 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.

Audience

A named group of notification recipients (Slack channels, emails, PagerDuty and others) that monitors notify when they alert.

In the API: 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: 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 the domains of the tables for alerts without a monitor; 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).

Event

A single detection on an asset (anomaly, schema change, rule breach, job failure); one or more events make an alert.

In the API: event_item, event_count.

Integration (warehouse)

A connected data source whose assets Monte Carlo monitors.

In the API: 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: 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.

Monitor tag

A key:value label on monitors, often used for team ownership (for example team:finance).

In the API: monitor_tag.

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.