Data Observability: A Practical Guide

A support rep opens a ticket. The CRM says the customer is on the free plan. The customer says they upgraded yesterday. The sync that moves Stripe subscription data to HubSpot has been silently failing for three days because someone renamed a custom property. Nobody got an alert. Nobody noticed. This is the gap data observability is supposed to close, except every vendor explanation of the term assumes you have a data warehouse, a data engineer, and a $30k annual subscription to a tool like Monte Carlo. Most teams have none of those. They still have the gap.

This guide walks through what data observability actually means, the five signals every practice tracks, and what each signal looks like when your data flows tool-to-tool instead of into Snowflake. Then it covers the practical question almost no other article addresses: how to get data observability when a separate vendor is overkill.

What data observability means (and the warehouse-centric definition every vendor uses)

Read three vendor blog posts on data observability and the pattern is identical. A data engineer ships a model to Snowflake. A dashboard breaks. Monte Carlo catches the freshness drop. The data engineer fixes the model. The dashboard recovers. The reader is meant to nod along and book a demo.

That scenario describes a narrow slice of how data moves through a company. It is not the most common slice. For every team running a warehouse-and-dbt stack, ten more teams move customer data directly between HubSpot, Stripe, Customer.io, Intercom, and a Postgres database. Their pipelines are not dbt models. Their alerts are not Slack messages from Monte Carlo. Their data still breaks in exactly the same ways.

The general definition is broader than the warehouse-first framing implies. Data observability is the practice of knowing, in near-real time, whether the data your downstream consumers are acting on is current, correct, and complete. It is the same idea as application observability (the term originated in control theory before software engineering borrowed it), applied to data systems instead of services. The "system" in question can be a dbt project. It can also be a set of syncs between SaaS tools. The signals are the same either way.

Here is the operator's version of the definition: you have data observability when you can answer "is my data good right now?" without opening five different tools and grepping through logs. Everything else is a vendor pitch.

The five signals every data observability practice tracks: freshness, volume, schema, lineage, quality

Every credible data observability framework settles on roughly the same five signals. Monte Carlo lists them as pillars. Bigeye and IBM publish slightly different versions. The definitions in industry research line up too. The names vary. The substance is identical.

The reframing matters because the same signals exist in both worlds. They just surface in different places.

Take freshness. In a warehouse stack, freshness is a property of a table. The last dbt run populated it twelve minutes ago. In a tool-to-tool sync stack, freshness is a property of a sync config. The last successful run of the Stripe-to-HubSpot subscription sync was twelve minutes ago. Both answer the same operator question: how stale is the data I am about to act on?

Volume works the same way. A warehouse tool flags it when a table that usually gets 50,000 rows per day gets 800. A sync platform flags it when a config that usually pushes 200 records per run pushes zero. Same signal. Different surface.

Schema is where the warehouse-first framing actively misleads. In a warehouse, schema drift means a column was added or dropped in the source. In a tool-to-tool sync, schema drift means a destination field was renamed in the SaaS tool. The Stripe sync writes to a HubSpot custom property called subscription_status. Someone renames it to stripe_status. The sync silently writes to a property that does not exist. Three days later, the rep gets the wrong plan info. The signal is identical to warehouse schema drift, but no warehouse-focused observability tool will catch it because no warehouse is involved.

Lineage is the one signal where small teams genuinely need less of it than large teams do. Column-level lineage across 400 dbt models is hard. Lineage across 12 sync configs is something you can fit on a whiteboard. But it still matters. When a Salesforce contact has the wrong company name, lineage answers the only question that matters: which sync wrote this field, and which source did it come from?

Quality is the broadest of the five. Null spikes, distribution drift, failed validation tests, identifier collisions, type mismatches. In practice, quality issues show up at the destination's API: the HubSpot API rejected this record because the email field is malformed, the Salesforce API returned a validation error because a required field is missing, the Customer.io API truncated a string because the field length limit was exceeded. A sync platform that surfaces those errors at the record level is doing quality observability whether it calls itself an observability tool or not.

There is no industry-wide rule that says exactly five signals. Some vendors list six. Some collapse freshness and volume into one. The five-signal version is a convention, not a law.

Data observability vs. data quality vs. data governance — where each one starts and stops

These three terms get used interchangeably in vendor marketing, which is a disservice. They describe different things, and conflating them makes it hard to figure out which tool actually solves your problem.

Data quality is a property of the data itself. A record is high-quality when the values are accurate, complete, and consistent. A record is low-quality when the email field is n/a or the country is Unknown. Quality describes the state of a thing. It is a noun.

Data observability is the discipline of watching the system that produces, moves, and transforms data so that quality drops get detected. Quality is what observability monitors for. The two terms describe the same outcome from different angles. Quality is the thing you care about. Observability is the practice of paying attention to it.

Data governance is the policy layer above both. Governance answers "who owns this data, who can change it, what rules apply, and how do we prove compliance?" A governance program might require that customer email addresses are validated before they reach the CRM. Observability tells you whether that policy is actually being enforced at runtime. Governance writes the rules. Observability is how you verify them.

The practical version, for teams under 200 people:

• If your problem is "this field has bad values," start with quality

• If your problem is "I don't know when something broke," start with observability

• If your problem is "nobody knows who owns this data," start with governance

Most teams have all three problems at once. They tend to confuse them because vendors sell tools that span all three categories and the marketing collapses the boundaries.

Why operational teams need data observability without a Monte Carlo subscription

Here is the part competitor articles skip. They define data observability as something a data engineering team adopts to protect a warehouse. For a team without a warehouse, the conclusion is implicit: you don't have this problem yet, come back when you do.

That is wrong. Operational teams have the same problem. They have it worse, in some ways, because the consequences land directly on a customer instead of on an internal dashboard.

A few examples from teams I've talked to:

A SaaS company synced Stripe subscription data to HubSpot every 15 minutes. The sync ran fine for six months. Then Stripe deprecated a field (a normal part of the Stripe API versioning lifecycle), the sync started failing silently on every run, and the company spent a quarter sending discount offers to customers who had already upgraded. The technical problem was schema drift at the source. The operational problem was that nobody noticed for ninety days.

A B2B startup ran a nightly sync that pushed product usage data from their Postgres database into Customer.io. A migration on the Postgres side changed a column name. The sync continued running because the column was technically still present (it had been renamed via a SQL alias somewhere), but the data was wrong. The marketing team launched a re-engagement campaign aimed at active users. It went to customers who had churned.

An e-commerce team synced order history from Shopify into their email tool. Their integration partner pushed an update that changed the order of two fields in the API response. The sync now wrote shipping addresses into the customer name field. Customers received order confirmation emails addressed to "1247 Main Street."

These are not warehouse problems. There is no Snowflake involved. There is no data engineer to alert. The break happens at the sync layer, between two SaaS tools, and the consequences hit a customer instead of a dashboard. The discipline that catches them is exactly what data observability vendors call data observability. The framing just doesn't match.

The reason these teams don't buy Monte Carlo is straightforward. Monte Carlo costs roughly the same as a senior engineer's annual salary. It assumes a warehouse. It plugs into dbt. None of that applies. So they go without observability, and the silent failures continue, until someone finally connects the dots between three months of customer complaints and the sync that broke last quarter.

I don't think this means Monte Carlo is wrong. For teams running large warehouse stacks with multiple data engineers, it is probably the right call. It is just not the only place data observability matters.

How to get data observability for tool-to-tool sync without building a data engineering stack

For operational teams, the practical move is not to add a separate observability product. It is to use a sync platform that surfaces the five signals natively at the run and record level. This is where the warehouse-first definition stops being useful and the operational version starts.

What "native observability" should look like at the sync layer:

• Freshness: every sync config shows last successful run age. Records show their last-synced timestamp. Stale syncs get flagged before stakeholders notice.

• Volume: record counts per run, with anomaly detection on configs that usually push 10,000 records suddenly pushing 50. Profile counts surfaced at the source and destination.

• Schema: destination schema is checked on every run. A renamed or removed field stops the sync before it silently writes to a property that no longer exists. Source schema changes are flagged at the next run.

• Lineage: every destination field traces back to the source tool, source field, and sync config that produced it. When the wrong company name lands on a contact, you can answer "which sync wrote this" in one click.

• Quality: record-level validation results. Failed records are queued, not dropped. Errors are categorized (rate limit, validation failure, identifier collision, schema mismatch) so you can fix the systemic ones instead of chasing individual records.

A team that runs syncs with all five signals visible has data observability. They don't need to call it that. They don't need a separate vendor. They need their sync platform to surface what is already happening in their pipelines instead of hiding it.

This isn't a universal answer. If your team runs a large warehouse stack with dozens of dbt models and a dedicated data engineering org, a purpose-built warehouse observability vendor is probably worth the spend. The five signals look different inside a warehouse. They are table-level instead of run-level, and column-level instead of field-level. The tools built for that environment do real work that a sync platform does not.

But if your customer data lives in HubSpot, Stripe, Customer.io, Intercom, and Postgres, and the syncs between them are the pipelines that matter, the right move is to make those syncs observable. Not to buy another tool that observes a warehouse you do not have.

This is the part where, if you've read enough vendor blogs, you expect a paragraph about a specific product. Oneprofile surfaces all five signals at the sync level: last-run freshness, volume tracking with anomaly flagging, destination schema drift detection, source-to-destination field lineage, and categorized error views for quality. The audit trail captures who changed what config and when. None of it requires a warehouse. It is part of the platform that runs the syncs, not a layer bolted on top.

Adopt it or don't. The bigger point is that the warehouse-first definition of data observability has been holding back a category of teams who genuinely need the discipline and have been told, implicitly, that it isn't for them. It is. The signals are the same. The implementation is just different.