A pipeline that finishes without an error is not the same thing as a pipeline that delivered correct, complete data. Here is what real observability looks like in an Azure and Fabric estate, and why success and failure are the wrong two states to monitor for.
Ask most data teams how they know a pipeline is healthy, and the answer comes back the same way almost everywhere: it ran, and it did not throw an error. That is the entire health check on a lot of Azure and Fabric estates: a green tick in a monitoring blade somewhere, glanced at once a morning. The problem is that success and failure are only two of the states a pipeline can actually be in, and they are the two least useful ones for deciding whether you can trust what landed in the lake.
Most of the failure modes that actually cost people money never touch the orchestration layer at all.
A pipeline can fail quietly in a dozen ways
A schema drifts by one column and everything downstream still runs. A source system starts sending yesterday’s file again and the pipeline processes it happily. A currency field switches from GBP to EUR without anyone flagging it, and the numbers are wrong in a way no error handler was ever written to catch. Row counts can be within a normal range while the actual content is nonsense, because normal range is a volume check, not a correctness check.
What real observability actually watches
Freshness matters more than most teams treat it: a table that has not been touched in the window you expected is a signal, whether or not the job that feeds it reported success. Volume matters, but as a distribution over time rather than a single pass or fail threshold, so a pipeline that normally lands two million rows and lands four hundred gets flagged even though four hundred rows is not technically an error. And schema and lineage both need watching together, because a column rename three hops upstream in Data Factory or a Fabric pipeline can silently null out a measure two dashboards downstream.
Alerting that people actually trust
The honest reason most teams turn off pipeline alerts within a month is that the first version pages someone at 2am for a warning that fixes itself, and after the third false alarm nobody trusts the channel enough to act on the real one. Alerts that survive need thresholds tuned to what a person can actually do about them, a severity that matches the blast radius, and a route to someone who owns the fix rather than a shared inbox everyone assumes someone else is reading. Fabric’s anomaly detection can plug into the alerting tools a team already lives in rather than adding another dashboard nobody opens, which matters more for adoption than the sophistication of the model underneath it.
What this means for you
None of this requires exotic tooling. It requires deciding what freshness, volume and schema stability actually mean for each critical dataset, wiring those checks into alerts that go to someone who can act, and treating a green pipeline run as the start of the health check rather than the end of it. That discipline sits close to how a bronze layer should be treated, and it connects directly to the governance decisions a business needs before AI is allowed near the same data.
If you want a second pair of eyes on what your own pipelines would actually catch today, get in touch and we will walk through it with you.
Shauna Duffy
Data Engineering Lead
Part of the Hopton Analytics team, delivering governed analytics programmes for UK mid-market organisations.