When pipelines run slow or fail silently, you need more than hope — you need visibility. This lesson teaches you how to use the Fabric Monitoring Hub and Capacity Metrics app to track activity, diagnose failures, and understand what your workloads are actually costing your capacity.
You've built a lakehouse, wired up some data pipelines, and everything appears to be working. Then one morning you open Power BI and the reports are slow. A colleague mentions that a Spark notebook ran last night and "seemed to take forever." Your scheduled pipeline finished two hours late. You have no idea why — because you haven't set up any monitoring yet.
This is the moment every Fabric practitioner eventually hits. The platform is doing work on your behalf, consuming compute resources from a shared capacity pool, and without a way to observe that activity, you're flying blind. The good news is that Microsoft Fabric ships with two purpose-built tools for exactly this problem: the Monitoring Hub, which gives you a workspace-level view of all item activity, and the Microsoft Fabric Capacity Metrics app, which gives you a deeper, capacity-level view of compute consumption over time. Together they answer the two most important operational questions: What ran? and What did it cost?
By the end of this lesson you'll be able to navigate both tools confidently, interpret the signals they surface, and take practical action when something looks wrong — whether that's a runaway pipeline, a notebook consuming too much Spark compute, or a capacity that's being pushed to its limits.
What you'll learn:
Before diving in, you should have a working Microsoft Fabric environment. If you haven't set one up yet, start with Fabric Capacities and Workspaces: F SKUs, Trials, and Setting Up Your First Workspace — that article explains the difference between F SKUs and trials, and walks you through creating your first workspace.
It also helps to have at least one or two items running in your workspace — a data pipeline, a Dataflow Gen2, or a Spark notebook. The monitoring tools are most instructive when there's actually something to monitor.
Before opening any dashboard, it's worth building a mental model of what Fabric is actually measuring.
Fabric runs on capacities — pools of compute and memory that you purchase or trial. Everything you do in Fabric (running a pipeline, querying a warehouse, refreshing a dataflow, executing a Spark notebook) consumes a share of that capacity's compute resources. Microsoft measures this consumption in Capacity Units, or CUs. Think of CUs the way you'd think of horsepower in a car: the more demanding the workload, the more CUs it burns, and the faster you can exhaust your available power.
Fabric capacities work on a smoothing model. If a heavy job temporarily spikes your usage above your capacity's rated limit, Fabric doesn't immediately throttle you — it averages consumption over a 10-minute rolling window. But if you sustain high usage over a longer period (the window expands to 60 minutes for more severe overages), Fabric will start throttling new operations. Sustained extreme usage triggers outright rejection of new requests until the capacity "catches up."
Key insight
The smoothing model means a single burst rarely causes visible problems. It's repeated heavy workloads — nightly pipeline runs, large Spark jobs, and Direct Lake queries all happening at once — that accumulate debt and cause throttling. This is why looking at trends over days matters, not just single run durations.
Understanding this model is what makes the Capacity Metrics app genuinely useful rather than just a pretty chart. You're not just looking at whether something ran — you're looking at whether the pattern of what ran is sustainable.
The Monitoring Hub lives inside the Fabric portal. To get there, navigate to your Fabric workspace (at app.fabric.microsoft.com) and look at the left-hand navigation panel. About halfway down you'll see a gauge-like icon labeled Monitor. Click it.
Alternatively, when you're already inside a workspace, you can access the Monitoring Hub by clicking Monitor in the workspace's left sidebar. The hub opens as a full-page view that immediately shows you a list of recent activity across all items in the workspace.
Note
The Monitoring Hub shows activity scoped to the workspace you're currently viewing. If you have data pipelines across multiple workspaces, you'll need to visit each workspace's Monitoring Hub separately. The Capacity Metrics app, by contrast, covers an entire capacity.
The main Monitoring Hub view displays a scrollable table of item runs. Each row represents a single execution of a Fabric item — one run of a data pipeline, one dataflow refresh, one notebook execution, and so on. The columns you'll spend the most time with are:
Name — The name of the item (e.g., "Load_Bronze_Sales") along with its item type (pipeline, dataflow, notebook).
Status — This is the most important column. Statuses include:
Start Time / End Time / Duration — Together these tell you when a run happened and how long it took. A pipeline that normally runs in 12 minutes but suddenly took 47 minutes is worth investigating even if it succeeded.
Triggered By — Shows whether the run was manual, scheduled, or triggered by another item (e.g., a parent pipeline calling a child pipeline as a child activity).
When a workspace has been running for weeks, the activity list can contain hundreds of entries. Use the filter bar at the top of the Monitoring Hub to narrow things down. You can filter by:
A productive habit is to start each morning by setting the filter to Status = Failed and Date = Last 24 hours. This gives you an immediate triage view of anything that broke overnight.
The Monitoring Hub's summary view tells you that something failed. The detail view tells you why.
Click on any pipeline row in the activity list. A detail panel slides in from the right showing the run's metadata — duration, trigger type, any input parameters that were passed. At the bottom of this panel you'll see a View run details link. Click it.
This opens the pipeline's activity-level run view. You'll see a visual representation of the pipeline canvas with each activity shown as a node. Each node has a colored status indicator:
Tip
When you see a mix of red failures and grey skips in a pipeline run, always investigate the first red failure. Skipped activities are usually innocent — they were simply never given the chance to run because something upstream broke.
Click on any individual activity node to see its input and output JSON. For a Copy Activity in a data pipeline, the output will show you how many rows were read, how many were written, the duration of the read and write phases separately, and whether any data was skipped. This is invaluable when a copy activity reports success but your destination table has fewer rows than expected.
For a failed activity, the output will contain an errorCode and a message. Common messages you'll encounter:
"The specified blob does not exist" — your source path is wrong or the file hasn't arrived yet"Access to the resource is forbidden" — a credential or permission issue on the source or destination"Operation timed out" — the activity ran longer than its configured timeout"The query has been cancelled due to resource limitations" — the capacity was throttled during executionThat last one is particularly important — it connects pipeline failures directly to capacity health, which is where the Capacity Metrics app comes in.
Warning
Timeout errors in a Copy Activity don't always mean the destination is empty. The write might have partially completed before the timeout. Always validate row counts in the destination table alongside reviewing the pipeline failure, especially when writing to a lakehouse table that downstream models depend on.
Pipelines aren't the only items that show up in the Monitoring Hub. Dataflow Gen2 refreshes and Spark notebooks appear there too, and they each have their own monitoring nuances.
When a Dataflow Gen2 refresh appears in the Monitoring Hub, clicking into the detail view shows you the individual query steps that executed inside the dataflow. If a refresh failed partway through, you can usually see which query step caused the error. Common issues include authentication expiry on a source connector, schema drift (a column that disappeared from a source API response), or a query that exceeded the dataflow compute timeout.
Dataflow refresh duration is also a useful signal for capacity planning. If your daily dataflow refresh normally takes 8 minutes but has been creeping toward 20 minutes over the past two weeks, that's a sign either your data volume has grown or the capacity is under more general pressure during that time window.
Spark notebooks show up in the Monitoring Hub with a duration that reflects the entire notebook execution. However, this doesn't tell you which cells were slow. For detailed Spark performance, you need to look at the Spark monitoring interface — accessible by clicking View Spark monitoring in the notebook's detail panel. This opens a job-and-stage breakdown showing the duration of each Spark stage, shuffle read/write volumes, and task-level metrics.
For most foundational use cases, you won't need to go this deep. But if a notebook is consistently slow, the Spark monitoring view will tell you whether the bottleneck is data shuffle (a sign you need to optimize your PySpark logic) or simply the sheer volume of data being processed.
The Monitoring Hub tells you about individual item runs. The Microsoft Fabric Capacity Metrics app tells you about the health of your entire capacity over time. These are complementary tools, not substitutes for each other.
The Capacity Metrics app is a Power BI app published by Microsoft into AppSource. To install it:
app.powerbi.com or navigate to the Power BI workloads section in Fabric.The app will pull utilization data from the past 14 days and refresh it periodically (roughly every 15 minutes for recent data).
Note
You need to be a Capacity Administrator to install and use the Capacity Metrics app. If you're working on a trial capacity you created yourself, you already have this role. On organizational capacities, you may need to ask your Fabric admin.
The app's home page shows a ribbon chart with time on the X axis and CU consumption percentage on the Y axis. The chart has three colored bands:
The ribbon is color-coded by workload type — you can see which portion of your consumption comes from pipelines, Spark, SQL analytics, Power BI semantic models, and so on. This is your first clue when investigating a throttling event: which workload was responsible?
Below the ribbon chart, the app shows a table of the top CU consumers over the selected time range. Each row is an item (a specific pipeline, a specific dataflow, a specific warehouse query) with its total CU-seconds consumed. Sort this table descending by CU consumption and you almost always find the 80/20 answer: a handful of items are responsible for the majority of your capacity bill.
Key insight
CU-seconds is the metric to care about, not just run duration. A Spark notebook that runs for 60 minutes on a large cluster consumes far more CUs than a pipeline copy activity that runs for 60 minutes moving files. Duration and cost are related but not equal.
The real power comes from using both tools together. Here's the workflow:
This detective work will almost always reveal the culprit — usually a combination of scheduled items that happen to overlap. The fix is often as simple as staggering pipeline schedules by 30 minutes so they don't all compete for capacity at 2 AM.
This exercise assumes you have at least one data pipeline in your workspace. If you don't, you can create a simple pipeline with a single Copy Activity that reads from a public URL and writes to a lakehouse Files section — the Loading Data into a Fabric Lakehouse with the Pipeline Copy Activity article walks through exactly this.
Part 1: Explore the Monitoring Hub
app.fabric.microsoft.com.Part 2: Build a Monitoring Habit
Part 3: Install the Capacity Metrics App (if you have Capacity Admin access)
app.powerbi.com and navigate to Apps → Get apps."My pipeline shows Succeeded but data didn't arrive in the destination." Check the Copy Activity output for rows written. It's possible the activity succeeded in the sense that it ran without error, but the source had zero rows matching your filter criteria. The activity reports success — it successfully copied nothing. Add a validation step or check row count logic in your pipeline parameters.
"I see Dequeued status for some runs." Dequeued means a run was queued but dropped before it started. This is almost always a capacity signal — the capacity was under enough pressure that Fabric decided not to admit new work. Check the Capacity Metrics app for that time window. If you see sustained high CU consumption, you need to either stagger your schedules, reduce workload intensity, or upgrade your SKU.
"The Monitoring Hub is empty even though I know things have run." The Monitoring Hub is workspace-scoped. Make sure you're in the right workspace. Also check that you have at least Contributor access to the workspace — Viewers cannot see all item activity in the Monitoring Hub.
"The Capacity Metrics app shows data from 14 days ago but not today." The app data has a refresh lag. Recent data (last few hours) may not appear immediately. Wait 15–30 minutes and refresh the Power BI app. For very recent activity, the Monitoring Hub is more current.
Warning
Don't rely on the Monitoring Hub's duration column alone when diagnosing performance problems. A pipeline that runs for 45 minutes but spends 40 of those minutes waiting for a queued Spark job will look slow in the Monitoring Hub but the root cause is capacity contention, not inefficient pipeline logic. Always correlate with the Capacity Metrics app before blaming the code.
"I can't find the View run details link for my notebook." Notebooks show a View Spark monitoring link rather than the pipeline-style activity canvas. If the run completed very quickly (under a few seconds), Spark monitoring data may not have been generated. This is normal for trivially short notebook executions.
Tip
Build a habit of bookmarking your workspace's Monitoring Hub URL directly. The default Fabric nav hides it a click away, and when something breaks at 7 AM the last thing you want is to hunt through menus.
You've covered a lot of ground. Here's what you can now do:
Monitoring isn't a one-time task. The data professionals who get the most out of Fabric are the ones who build a short daily habit: check the Monitoring Hub for failures, glance at the Capacity Metrics app for trends, and investigate anything that looks anomalous before it becomes a business problem.
From here, the natural next step is to think about governance and access control — who has permission to see and run what across your workspaces. The article on Securing and Governing Microsoft Fabric: Workspace Roles, Item Permissions, and OneLake Data Access picks up exactly where this one leaves off. You might also explore how version control and deployment pipelines can make your Fabric items more reliable and easier to promote across environments in Fabric Git Integration and Deployment Pipelines: Version Control and Promotion Across Environments.
If you're managing a more complex data architecture — for example, a medallion architecture with bronze, silver, and gold layers — the monitoring skills you've built here will help you quickly pinpoint which layer's processing is causing latency when your gold-layer reports arrive late.
Monitoring is what separates a Fabric environment that works from one that you can actually operate with confidence.