Monte Carlo

Overview

Monte Carlo defined this category and still publishes the framing everyone borrows: the five pillars of data observability, meaning freshness, distribution, volume, schema and lineage.

Note the name first, because older links mislead. montecarlodata.com now redirects to montecarlo.ai, the legal entity is Monte Carlo AI, and it markets itself as an agent trust platform for data and AI observability.

Monitoring comes in five categories, for tables, metrics, validations, jobs and agents, and only the table monitors are automatic. Those work immediately with no configuration, and importantly use metadata rather than querying the table.

Everything else needs configuring, which is the honest shape of the product: broad automatic coverage of the basics, deliberate work for the specifics.

Thresholds can be automated or manual. The automated ones run an ensemble of anomaly detection models trained on a rolling window, with sensitivity set low, medium or high to widen or tighten the band.

Root-cause analysis is where it pulls ahead, because it reads query logs. It surfaces which queries changed near an incident, which failed on timeout or permissions, and which succeeded but returned nothing.

Check that against your warehouse though: all insight types are available on Snowflake, BigQuery and Redshift, and data lakes such as Databricks lack the automated insights.

Lineage is built by parsing SQL with no manual mapping, reaching field level, and distinguishes direct field-to-field relationships from fields merely shaped by filtering logic.

Deployment is software as a service with hybrid extensions, agentless through private links, and a customer-hosted data store or agent if you want telemetry to stay closer to home. Regions are the United States and the EU.

It is the only tool in this category publishing real consumption rates, in credits per monitor per day, though the price of a credit is not published, so budgeting still needs a conversation.

Key features and capabilities

The same headings are used for every data observability entry, so two tools can be read side by side.

What it monitors

• Freshness against time since last update, and volume against row count and byte size
• Volume alerts distinguish increases, decreases, and no change where a change was expected
• Schema change and JSON schema monitors for semi-structured columns
• Metric and comparison monitors for distribution and column statistics, replacing the deprecated field health monitors
• Validation monitors, custom SQL rules, and query performance monitors for job failures and slowdowns

How incidents are detected

• Table monitors start working on connection with no configuration, using metadata rather than querying the table
• Automated thresholds run an ensemble of anomaly detection models trained on a rolling window
• Sensitivity is low, medium or high, widening or tightening the threshold and so the alert volume
• Exclusion windows and holiday handling stop known quiet periods training the model badly
• Manual thresholds are available on freshness and volume, scheduled periodically or by cron

Coverage and onboarding

• Table monitors need no table selection; metric, validation and job monitors are configured per asset
• Monitors as code in YAML, with a dry run estimating the daily credit cost before you apply it
• A monitoring agent claims to deploy sophisticated monitors in seconds, with a published acceptance rate
• Record-level troubleshooting samples are small and can be switched off entirely per integration
• Table importance is used to prioritise both monitoring and notification routing

Triage and root cause

• Alerts can be promoted to incidents, with documented statuses and an incident summary view
• Root-cause insights run automatically, correlating which field values coincide with an anomaly
• Query insights identify queries that changed, failed or returned zero rows near the incident
• Insight coverage varies by platform, with data lakes such as Databricks lacking automated insights
• Triage, troubleshooting, operations and pull-request agents, plus a loop turning traces into fixes

Lineage and impact

• Built automatically by parsing SQL, with no manual mapping
• Field level, distinguishing direct field-to-field dependencies from fields shaped by filtering logic
• dbt context is overlaid, showing latest model run status and timestamps
• Assets appear within hours of setup, lineage within a day
• BI coverage spans Tableau, Looker, Power BI, Mode and others, though field-level BI lineage is documented only for Tableau

Integrations

• More than 50 systems across eight categories, including warehouses, lakes and transactional databases
• dbt Core and dbt Cloud, Airflow, Fivetran, Informatica, Prefect and Databricks Workflows
• Catalogues including Alation, Atlan, Collibra, Select Star and data.world
• Alerting to Slack, Teams, PagerDuty, Opsgenie, Jira, ServiceNow and webhooks
• A GraphQL API, a CLI and a Python SDK, with daily API call ceilings differing by plan

Where it runs and what it costs

• Software as a service by default, connecting agentlessly through IP allowlisting or a private link
• Hybrid options put the data store, or the agent and data store, in your own cloud
• Regions are the United States and the EU, with some features not yet in the EU region
• A dedicated instance with disaster recovery on the top plan
• Priced per monitor in credits, with chargeback by line of business and a consumption export

Pricing

Price on requestQuote only; credit rates published

Four plans, Start, Scale, Enterprise and Business Critical, all quote-only with no currency figures and no free tier or trial published. What it does publish, uniquely here, is consumption in credits: table monitors from 1.75 credits a day per table falling sharply with volume, metric monitors from 1 credit, query performance monitors at 20 credits a day, and per-agent rates with small monthly free allowances. Since the price of a credit depends on your tier and is not published, those rates size a workload without costing it.

Vendor pricing page →

Demos and videos

• Monte Carlo platform demo Product demo · YouTube
• Monte Carlo product tour Tutorial · YouTube

About Monte Carlo

Monte Carlo was founded in 2019 by Barr Moses, its chief executive, and Lior Gavish, and is now legally Monte Carlo AI, Inc., formerly Monte Carlo Data, Inc.; it publishes no headquarters beyond a privacy-request mailing address in San Francisco. It is private, having raised $236m in total, through a $16m Series A led by Accel, a $25m Series B, a $60m Series C led by ICONIQ, and a $135m Series D in May 2022 led by IVP at a $1.6bn valuation, with nothing published since. It reports more than 400 enterprise customers and ten million tables monitored, naming PepsiCo, Cisco, Nasdaq and Disney.

Founded 2019 · montecarlo.ai