There’s a specific notification ring tone that makes my stomach drop to this day. For on-call engineers in the data org, it usually comes around 3AM and it’s normally when something is broken in production. 

Here’s what typically happens: You fumble for your laptop, connect to VPN, and see an error message that means nothing without context. Twenty minutes later, you’re paging teammates and pulling people into an emergency Zoom. By morning, your team is exhausted, stakeholders are angry, and you’re writing another postmortem.

After building data platforms at DoorDash and Bloomberg, here’s what became clear: most data quality alerts either don’t matter or are false positives. In our experience, data users (ML, data, and product engineers) care mainly about 20% of data as those drive the vast majority of business impact. The rest are experiments, staging data, and unused data. Between 60% and 73% of all data within an enterprise goes unused for analytics, according to Forrester Consulting. Yet teams spend equal time monitoring all of them, leading to alert fatigue.

We’ve discovered query logs are better predictors of data importance than any manual classification system. 

Tables accessed 100+ times daily we can infer are critical. Tables only touched during a monthly batch job is a signal that the data may not be as important. That staging table that hasn’t been queried in a year probably doesn’t need an alert at 3AM. 

On-call engineers normally ask 3 questions when they get paged: 

1. Is something actually broken?

2. Does anyone actually care? 

3. What should I do to fix it?

Current platforms try to answer these by adding context rich alerting. The context comes from catalogs, lineage graphs, historical fixes. But they still require weeks of manual setup to define what “important” means. 

Here’s what works: Start from consumption and work backwards.

Instead of monitoring every table equally, you look at query frequency, user patterns, and downstream impact. Tables that feed into critical dashboards should get priority. Data accessed by executives matters more than dev experiments. Tables that are upstream of critical processes should get prioritized. 

We’ve seen the same pattern with SRE teams. They monitor critical user paths, not every microservice equally.

Whether you’re building or buying monitoring, you do not want your engineers up at 3AM for false positives. This leads to burnout and attrition. Map out which datasets actually matter and determine the monitoring they need by following your users query patterns. 

At Sentinel, we’ve automated this approach so teams don’t waste weeks on setup. But even if you’re using another tool, stop treating all data equally. Monitor what matters, ignore what doesn’t.