What Azure monitoring is — and what it was built to solve
Azure monitoring is not a single product. It is a collection of services — Azure Monitor at the platform layer, native alerting inside individual services like ADF and Synapse, Power BI Service notifications at the BI layer, and specialized apps like the Fabric Capacity Metrics App — that each address a different operational concern.
Azure Monitor is the foundational telemetry platform. It collects logs, metrics, and traces from Azure resources, routes them to Log Analytics workspaces, and provides alerting rules, dashboards, and integrations with action groups. For infrastructure teams managing virtual machines, App Services, and AKS clusters, Azure Monitor is the right starting point: it surfaces CPU utilization, memory pressure, network errors, and platform-level health events across the Azure estate.
The problem for data teams is that Azure Monitor was designed for infrastructure observability, not data pipeline observability. When your concern is whether an ADF pipeline loaded the right rows, whether a Power BI dataset is showing current data, or whether a Fabric dataflow silently stalled — Azure Monitor requires significant customization before it is useful. The telemetry exists; the signal-to-noise ratio does not come out of the box.
Understanding what each Azure monitoring tool actually covers is the prerequisite for knowing what to build on top of it and what to buy elsewhere.
Azure Monitor: powerful telemetry platform, limited data pipeline signal
Azure Monitor ingests diagnostic logs and metrics from most Azure services via diagnostic settings. For ADF, enabling diagnostic settings routes pipeline run logs, activity run logs, and trigger run logs to a Log Analytics workspace. For Synapse, it captures distributed SQL pool metrics and pipeline events. For Azure Databricks, workspace-level audit logs are available.
With Log Analytics and KQL, a skilled engineer can build meaningful data pipeline alerts. A query that fires when an ADF pipeline fails is straightforward. A query that detects when a pipeline has not run within its expected schedule window requires tracking the last successful run timestamp and comparing it to the current time — buildable, but it needs maintenance every time the pipeline schedule changes.
Where Azure Monitor falls short for data teams is granularity and context. It can tell you that an ADF pipeline run failed. It cannot tell you which Power BI datasets are downstream of that pipeline and will now show stale data when they refresh. It has no concept of BI-layer impact. The alert fires for the infrastructure owner; the data consumer is left to discover the consequence themselves.
Azure Monitor also does not monitor Power BI dataset refreshes natively. Power BI Premium diagnostic logs can be sent to a Log Analytics workspace, but the coverage is limited to capacity-level events — not individual dataset refresh results. For Import mode datasets refreshing on a schedule, Azure Monitor has no visibility without significant custom instrumentation.
Finally, Azure Monitor alerts require engineering investment to build and ongoing investment to maintain. Alert rules written in KQL are not self-documenting, they do not adjust to pipeline schedule changes automatically, and they do not establish baselines — every threshold is a manual judgment call.
ADF native monitoring: the right starting point, not the complete answer
Azure Data Factory has its own monitoring surface in the Azure portal: the Monitor hub. It shows pipeline runs, activity runs, trigger runs, and integration runtime status. For teams that primarily live in the Azure portal, the ADF monitor hub is often the first place they look when something breaks.
ADF also supports native email alerts via Azure Monitor integration. You can configure an alert rule on the PipelineFailedRuns metric and attach an action group that sends an email when a pipeline fails. This is the baseline most ADF teams have in place — it is easy to set up and catches outright pipeline failures.
The limits of ADF native monitoring appear quickly in production. First, it only fires on failure — not on lateness. A pipeline that is supposed to run at 05:00 and has not started by 06:30 does not produce a PipelineFailedRuns metric. It produces nothing. The missing-run case — which is often the most damaging because it means a full refresh cycle is skipped — requires custom KQL to detect.
Second, ADF monitoring is activity-aware but not downstream-aware. When a copy activity fails, you know the copy failed. You do not know which dbt models consume the output table, which Power BI datasets refresh from those models, or which reports will show stale data at 08:00. The blast radius is invisible from the ADF layer.
Third, ADF monitoring has no baseline concept. A pipeline that normally completes in 12 minutes but today runs for 47 minutes generates no alert — it is still running, so technically not failed. By the time it finishes or times out, the Power BI refresh that depended on it may have already started on incomplete data.
Power BI Service alerts: refresh notifications with no upstream context
Power BI Service provides two types of built-in alerting. Data alerts allow report owners to set threshold-based alerts on specific visual values — when a KPI card crosses a configured value, an email is sent. Refresh failure notifications send an email to the dataset owner when an import-mode dataset refresh fails.
For individual dataset owners, refresh failure notifications are genuinely useful. They arrive quickly, identify the failing dataset, and include a basic error message. For a data team managing 50-plus datasets, they create a noise problem: every failure goes to the dataset owner, with no central inbox, no prioritization, and no context about which failures are related.
Power BI also offers data-driven alerts only within Power BI itself — you cannot route a Power BI refresh failure to a Slack channel, a Telegram group, a PagerDuty incident, or a webhook without building a Power Automate flow or using a third-party tool. The native alerting is email-only.
More fundamentally, Power BI Service alerting has no upstream awareness. When a dataset refresh fails with a DataSource.Error — the source query returned an error — Power BI tells you the dataset failed. It does not tell you whether the failure is because the ADF pipeline that populates the source table ran late, because a dbt model transformation failed, or because the Snowflake warehouse suspended due to a billing issue. Root cause analysis is a manual process that starts from the Power BI error message and traces backward through the stack.
For teams running Power BI on top of ADF, Databricks, or dbt, this upstream blindness is where most of the investigation time goes. The symptom is visible in Power BI. The cause is elsewhere.
Fabric Capacity Metrics App: infrastructure view, not pipeline view
Microsoft Fabric introduced the Capacity Metrics App as the primary monitoring surface for Fabric capacity consumption. The app shows CU (compute unit) utilization by workload, smoothing, throttling events, and capacity headroom over time. For Fabric admins responsible for right-sizing capacity and managing overages, it is the correct tool.
For data engineers monitoring Fabric pipelines and dataflows, the Capacity Metrics App answers the wrong question. It tells you how much compute your workloads consumed; it does not tell you whether a specific Fabric pipeline succeeded, what its output row count was, whether it ran late relative to its schedule, or what the downstream impact on Fabric reports was.
Fabric dataflows (Gen 2) have their own refresh history in the Fabric portal, accessible per workspace and per dataflow. The history shows run status and duration. It does not integrate with Azure Monitor, does not support native webhook alerting, and does not show cross-workspace lineage. If a Fabric dataflow fails at 04:00 and no one checks the portal until 09:00, the failure has been silent for five hours.
Fabric pipelines (the ADF-like orchestration layer within Fabric) have similar monitoring gaps. Run history is available in the portal. Native alerting is limited. Cross-tool lineage to downstream Fabric semantic models or Power BI reports is not surfaced in the monitoring view. Teams that have migrated from ADF to Fabric pipelines often discover they have also lost the monitoring posture they had with ADF diagnostic settings in Azure Monitor.
Where MetricSign fills the gaps in the Azure monitoring stack
The gap across all four Azure monitoring tools is the same: each tool watches its own layer and does not connect to the layers above or below it. A failure in ADF does not automatically surface in Power BI monitoring. A slow Fabric dataflow does not trigger an alert before the downstream report refresh starts. A missing pipeline run that leaves data 24 hours stale generates no signal anywhere.
MetricSign is built specifically to close these cross-layer gaps. It connects to ADF, Fabric, Power BI, Databricks, dbt, Snowflake, and other data tools via their native APIs — the same APIs that Azure Monitor uses for diagnostic logs — and builds a unified lineage graph that links pipeline runs to the BI datasets and reports they feed.
When an ADF pipeline runs 25 minutes later than its historical baseline, MetricSign detects the lateness, checks which Power BI datasets have scheduled refreshes that depend on that pipeline's output, and sends an alert before those refreshes start on incomplete data. This is a signal that none of the four native Azure tools produce.
For Power BI specifically, MetricSign adds the monitoring signals that Power BI Service lacks: volume anomaly detection (did the dataset load an unusually small number of rows?), schedule drift (is the refresh taking longer over time, approaching the SLA window?), and stale data detection (is the maximum timestamp in the loaded data consistent with what a fresh load should look like?). These checks run after every refresh, via the Power BI REST API, without any changes to datasets or reports.
For Fabric, MetricSign monitors dataflow and pipeline run history and fires alerts on failures and lateness — filling the alerting gap that exists between the Fabric portal's run history view and the Fabric Capacity Metrics App's capacity view. The result is a single incident feed that covers all layers of the Azure data stack, routed to the channels your team actually uses: email, Telegram, or webhook.