JetBlue's data team had a problem they couldn't see. After migrating to Snowflake, the airline was managing 3,400 analyst-facing tables across 5 petabytes of data, and their internal Data NPS score was, as Brian Pederson, Manager of Data Products, put it, "a bit lower than we wanted." The issue wasn't the data itself. It was that nobody knew when the data was wrong until someone downstream complained.
This scenario plays out across enterprises daily. According to IBM's 2025 research, over a quarter of organizations estimate they lose more than $5 million annually due to poor data quality, with 7% reporting losses exceeding $25 million. Gartner's figures put the average cost at $12.9 million per organization per year. The math is brutal, but it's also fixable.
The Detection Gap
Most data quality incidents surface the same way: an analyst opens a dashboard, notices something wrong, and fires off an email. By then, the data has been incorrect for hours, sometimes days. Monte Carlo's benchmark data suggests that 90% of data downtime incidents are detected by downstream consumers rather than proactive monitoring. The result is a reactive firefighting culture where data engineers spend 30 to 40 percent of their time handling quality issues instead of building.
JetBlue's experience illustrates the shift from reactive to proactive. As Ashley Van Name, Senior Manager of Data Engineering, explained in the company's case study:
Before we onboarded Monte Carlo, the data operations team's primary focus was to just monitor pipeline runs that failed. But now, they've got this extra level of insight where they're able to say 'something is wrong with this table' rather than just 'something is wrong with this pipeline.'
Ashley Van Name, Senior Manager of Data Engineering, JetBlue
The distinction matters. A pipeline can complete successfully while delivering incorrect data. Without observability at the table and field level, you're flying blind.
Quantifying the Improvement
The case studies from Monte Carlo's customer base reveal consistent patterns in measurable outcomes. M&T Bank reduced time to resolution by 90% after implementing data observability. For a super-regional bank serving millions of customers, that compression translates directly into reduced risk exposure and faster decision-making.
Calendly's data team saw a 40% reduction in data-related bug tickets. Their journey is instructive: the company had outgrown its original Redshift setup, where the only safety net was what they called "scream tests," meaning problems only surfaced when something broke loudly in production. After migrating to BigQuery and implementing Monte Carlo, they shifted from reactive firefighting to proactive quality management.
Resident, an online mattress and homegoods company managing over 30,000 BigQuery tables, reported reducing data incidents to 10% of their previous volume. As their director of data engineering noted in Monte Carlo's use case documentation:
We have 10% of the incidents we had a year ago. Our team is super reliable, and people count on us.
Director of Data Engineering, Resident
The Trust Metric
JetBlue's 16-point improvement in internal Data NPS deserves attention because it captures something harder to quantify than incident counts: organizational trust. Brian Pederson framed it well:
Data trust is a human emotion, which isn't always entirely rational. But if you can give the analysts access to [Monte Carlo] where they can see the health of all the data objects they are using, you can sell them on the data's quality.
Brian Pederson, Manager of Data Products, JetBlue
This matters for marketing and revenue operations specifically. When your attribution models, pipeline forecasts, and campaign performance dashboards rest on data that stakeholders don't trust, they build shadow systems. They export to Excel. They add manual checks. Each workaround adds friction and introduces new error vectors.
The Federated Model
M&T Bank's approach offers a template for scaling data quality without scaling headcount linearly. Andrew Foster, the bank's Chief Data Officer, described the challenge:
As a cost center, the data office needed to deliver outsized value without significant headcount growth. Simply adding more analysts or rule writers was not an option.
Andrew Foster, Chief Data Officer, M&T Bank
Their solution combined automated anomaly detection with business-owned quality rules. Different stakeholders had different requirements: risk teams needed rapid signals even with imperfect data, while finance teams required absolute precision. The observability platform had to support both without compromise.
The federated ownership model pushes quality responsibility to domain experts while centralizing visibility. Data stewards in each business unit define what "good" looks like for their data products. The platform enforces those definitions and surfaces violations before they propagate downstream.
The AI Readiness Question
IBM's research found that 45% of business leaders cite concerns about data accuracy or bias as a leading barrier to scaling AI initiatives. The reason is straightforward: AI systems inherit and amplify data quality issues. A model trained on inconsistent, incomplete, or biased data produces unreliable outputs at scale.
Monte Carlo's evolution reflects this shift. The company, which coined the term "data observability" in 2019, has expanded its platform to cover AI agent observability. The five original pillars, freshness, quality, volume, schema, and lineage, remain foundational, but production AI introduces new failure modes that require new monitoring approaches.
For marketing teams deploying AI-powered personalization, recommendation engines, or predictive lead scoring, the data quality question becomes existential. A model that recommends the wrong products or scores leads incorrectly doesn't just waste compute; it actively damages customer relationships and pipeline quality.
Building the Business Case
The ROI calculation for data observability follows a predictable structure. Start with the cost of data engineering time spent on reactive firefighting. Monte Carlo's estimates suggest 30 to 40 percent of data team capacity goes to quality issues. For a five-person team at fully loaded costs, that's 1.5 to 2 FTEs worth of capacity.
Add the downstream impact: delayed reports, incorrect dashboards, flawed forecasts. DQLabs' research suggests leading enterprises realize 3x to 4x ROI from observability investments when implemented effectively. The key qualifier is "when implemented effectively," meaning starting with high-impact data products, automating monitoring with ML rather than manual rules, and integrating observability into existing workflows.
The pilot approach works. One global manufacturer in DQLabs' research began by monitoring just a few supply chain feeds, quickly reduced reporting errors, and used that success to justify broader adoption. The pattern repeats across case studies: prove value on a critical pipeline, document the improvement, expand.
What the Numbers Mean for Your Forecast
If your data team spends more than 20% of their time on reactive quality issues, you have an observability problem. If your stakeholders maintain shadow systems because they don't trust the official dashboards, you have a trust problem. If your AI initiatives stall because nobody can certify the training data, you have a readiness problem.
The case studies suggest these problems are solvable with measurable timelines. JetBlue saw their Data NPS improve within a year. Calendly reduced bug tickets by 40%. M&T Bank compressed resolution time by 90%. The numbers vary by organization, but the direction is consistent.
The question isn't whether data observability delivers ROI. The question is whether you can afford the ongoing cost of not knowing when your data breaks.
