MetricSign
Start free

Microsoft Fabric Monitoring: Beyond the Monitoring Hub

The Fabric Monitoring Hub shows a list of completed and failed item runs. It doesn't tell you whether the pipeline that was supposed to run at 06:00 ever started, which Power BI datasets are now loading stale data, or what the error code in the failed Dataflow Gen2 run actually means.

Microsoft Fabric includes native monitoring through the Monitoring Hub and Workspace Monitoring. Both are event-driven: they record runs that happened. Three gaps remain: missing run detection, cross-stack impact visibility (Fabric failures → Power BI datasets), and resolution guidance for Fabric-specific error codes.

MetricSign vs Fabric Native

Feature
MetricSign
Fabric Native
Pipeline and dataflow failure detection
Automatic incident creation per failure; severity classification; grouped across related items in the same data chain
Monitoring Hub shows failed runs; workspace admins can configure email alerts via Data Activator
Missing run detection
Schedule learning; incident fires when an expected Fabric pipeline or Dataflow Gen2 run does not appear within the learned window
Monitoring Hub is event-driven — a pipeline that never starts produces no log entry and no alert
Error code translation + fix guidance
Fix Tab: human-readable explanation of Fabric-specific error codes with step-by-step resolution and direct links to relevant settings
Error messages surface as raw codes in the Monitoring Hub activity details; resolution requires documentation lookup
Downstream Power BI impact
Automatic lineage: Fabric pipeline failure is linked to affected Power BI semantic model refreshes; one incident covers the full chain
~Within-Fabric lineage exists for Fabric items; cross-tool impact on Power BI semantic models is not automatically correlated
Cross-stack monitoring (dbt, Databricks, Snowflake, ADF)
Single incident view across Microsoft Fabric, ADF, Databricks, dbt Cloud, dbt Core, Snowflake, and Power BI
Fabric monitoring is scoped to Fabric items; upstream dbt, Databricks, or ADF failures require separate tools
Incident lifecycle (open / track / resolve)
Auto-open on failure, track through resolution, auto-close on recovery — with full timeline and acknowledgement
Monitoring Hub shows current and historical status; no incident state management, acknowledgement, or resolution tracking
Alert channels
Email, Telegram, Slack, Teams, and webhook; no additional Fabric configuration required
~Data Activator supports email and Teams alerts for specific Fabric events; webhook delivery requires additional setup
Capacity utilisation monitoring
Fabric capacity metrics tracked alongside pipeline health; CU spike correlation with specific item runs
Microsoft Fabric Capacity Metrics app provides detailed CU consumption breakdowns by workspace and item
Supported
~Partial / limited
Not supported

What Fabric native monitoring covers — and where it stops

Microsoft Fabric provides two primary monitoring mechanisms. The Monitoring Hub gives workspace users a real-time view of running and completed item executions across pipelines, Dataflow Gen2 runs, Spark jobs, and semantic model refreshes. Workspace Monitoring, when enabled, collects logs and metrics into a dedicated Eventhouse, making them queryable via KQL.

Data Activator adds alerting capability: rules can fire on specific Fabric item events and send email or Teams notifications.

Three gaps remain regardless of which mechanism you use.

First, both tools are event-driven. A Fabric Data Factory pipeline scheduled for 06:00 that never triggers produces no Monitoring Hub entry and no Data Activator alert. The first signal is a Power BI report showing yesterday's data at 09:00.

Second, error codes surface without resolution context. A Dataflow Gen2 failure shows an error string in the Monitoring Hub activity details; what caused it and how to fix it requires a separate documentation search.

Third, Fabric monitoring stays within Fabric. When a dbt Cloud model build fails at 02:00, an ADF pipeline times out at 02:30, and the Fabric Dataflow Gen2 refresh fails at 03:00 — three separate monitoring consoles show three separate events. The connection between them is invisible.

Fabric monitoring within a mixed data stack

Most Fabric deployments sit inside a broader data stack. Source data arrives from Snowflake, Databricks Delta tables, or Azure SQL. Transformation runs in dbt Cloud or ADF. The final step — loading into Fabric OneLake and refreshing the Power BI semantic model — is what end users see.

When the Fabric pipeline fails at 03:00, the root cause is often not Fabric. It is a Snowflake timeout at 01:45, a dbt model that failed silently at 02:10, or an ADF activity that hit a credential expiry. Fabric's Monitoring Hub shows the Fabric failure clearly; it shows nothing about what happened upstream.

MetricSign monitors the full chain simultaneously. The dbt failure at 02:10, the ADF timeout at 02:30, the Fabric Dataflow Gen2 failure at 03:00, and the Power BI semantic model failure at 04:00 are grouped into one incident — with the dbt failure identified as the earliest point of failure in the chain.

The Fix Tab translates each error in the chain into plain English with resolution steps and direct links to the relevant Fabric, ADF, dbt, or Power BI settings pages.

When Fabric native tooling is sufficient

If your data stack is entirely within Microsoft Fabric — Fabric pipelines, Fabric Data Warehouse, Fabric Dataflow Gen2, and Power BI semantic models, with no external dbt, Databricks, Snowflake, or ADF components — the Monitoring Hub and Workspace Monitoring cover most operational needs.

Data Activator provides adequate alerting for teams that monitor Fabric through Microsoft Teams and don't require Slack, Telegram, or webhook delivery.

The native tooling does not solve missing run detection or provide fix guidance for error codes. For teams where a missed overnight run costs more than a few hours of investigation, those gaps justify a dedicated tool.

MetricSign pricing: €299/month per organisation. 45-day trial, no credit card.

Frequently asked questions

What is the Microsoft Fabric Monitoring Hub?

The Monitoring Hub is a centralised view in the Fabric portal that shows the execution status of all Fabric items in your workspace — Data Factory pipelines, Dataflow Gen2 runs, Spark jobs, Notebooks, and semantic model refreshes. It displays current runs, completed runs, and failures with activity-level detail. It does not detect missing runs (pipelines that never started) and has no incident lifecycle management.

How do I set up alerts for Microsoft Fabric pipeline failures?

Native option: Data Activator in Microsoft Fabric can trigger email or Teams notifications when specific Fabric items fail. Setup requires configuring a Reflex in Data Activator against the relevant Fabric item. Limitation: one-shot notifications per event, no incident tracking, no Slack, Telegram, or webhook delivery without additional Azure services. MetricSign provides out-of-the-box email, Telegram, Slack, Teams, and webhook alerts with full incident lifecycle management — setup takes approximately 10 minutes.

Does Microsoft Fabric detect when a pipeline doesn't run?

No. The Monitoring Hub and Data Activator are event-driven: they only record runs that actually occur. If a scheduled Fabric pipeline never starts — due to a disabled trigger, a capacity throttle, or a dependency stall — no alert fires and no log entry appears. MetricSign learns the expected schedule for each item and opens an incident when a run does not appear within the learned window.

Can I monitor Fabric pipelines and Power BI together?

With native Fabric tooling, partially: Fabric has internal lineage for Fabric items, but failures in upstream non-Fabric tools (ADF, dbt, Databricks) and their impact on downstream Power BI semantic models are not automatically correlated. MetricSign monitors the full stack — Fabric, ADF, dbt Cloud, dbt Core, Databricks, Snowflake, and Power BI — and groups related failures into one incident.

What monitoring tools exist for Microsoft Fabric?

Native: Fabric Monitoring Hub (activity status), Workspace Monitoring (KQL-queryable logs via Eventhouse), Data Activator (event-based alerts to email/Teams), and the Fabric Capacity Metrics app (CU consumption). Third-party: MetricSign monitors Fabric pipelines, Dataflow Gen2, and semantic model refreshes with missing run detection, error translation, cross-stack incident correlation, and alerting via email, Telegram, Slack, Teams, and webhook.

Does MetricSign connect to Microsoft Fabric?

Yes. MetricSign connects to Microsoft Fabric via the Fabric REST API and Power BI REST API. It monitors Data Factory pipelines, Dataflow Gen2 runs, and Power BI semantic model refreshes within your Fabric capacity. Incidents are correlated with upstream ADF, dbt, Databricks, and Snowflake runs. Setup takes approximately 10 minutes and requires a service principal with Fabric Contributor access.

Related articles