What the Fabric Capacity Metrics app is
The Fabric Capacity Metrics app is a Power BI report that Microsoft makes available to Fabric capacity administrators. It connects to Fabric's telemetry API and displays consumption data for a selected capacity over a configurable time window. The app is not a real-time monitoring dashboard — it shows historical metrics with a delay of typically 2–15 minutes depending on the workload type and activity volume.
The app is installed from AppSource and deployed into a Power BI workspace with administrator privileges. It is updated by Microsoft as Fabric evolves, so the interface and available metrics change over time. As of mid-2026, the app covers CU consumption by workload item, interactive vs background operation classification, throttling events, and smoothing windows — the mechanisms Fabric uses to spread burst usage across a 10-minute period.
For capacity administrators trying to understand whether a capacity is appropriately sized, the Fabric Capacity Metrics app is the authoritative source. For data engineers trying to understand why a specific pipeline failed at 06:15 AM, it is the wrong tool — it tells you what the capacity was doing, not whether individual workloads succeeded.
The distinction matters because Fabric has a mixed workload model. Semantic model refreshes, dataflow Gen2 runs, Fabric pipeline orchestration, Spark notebook execution, and OneLake operations all consume CU from the same pool. The Capacity Metrics app aggregates these into CU time curves. Whether any individual job within that CU usage succeeded or failed is outside its scope.
Reading the Capacity Metrics app: CU consumption, throttling, and smoothing
The app's primary visualization is a time-series chart of CU consumption overlaid against the capacity's total CU allocation. The x-axis is time (typically shown in UTC), and the y-axis shows CU seconds consumed in each 30-second reporting window. A horizontal line represents the capacity's total allocation — the point above which throttling begins to apply.
Interactive operations vs background operations
Fabric classifies operations into two categories. Interactive operations include DAX queries, report rendering, and on-demand data refreshes triggered by a user action. Background operations include scheduled refreshes, pipeline runs, Spark jobs, and dataflow executions that run without direct user initiation. The distinction matters because Fabric applies different throttling rules to each: interactive operations are protected from heavy throttling to preserve user experience, while background operations can be queued or slowed more aggressively during high-utilization periods.
The Capacity Metrics app shows interactive and background CU consumption separately, which tells you whether a spike was caused by a user-triggered workload or a scheduled pipeline.
Smoothing windows
Fabric does not apply throttling on a per-second basis. Instead, it uses a 10-minute smoothing window: if a burst of CU consumption in one 30-second period pushes utilization above the capacity limit, Fabric distributes the excess across the next 10 minutes rather than immediately throttling. This means a workload can spike significantly above the capacity line without causing immediate user-visible throttling — but if the burst is large enough or sustained, the smoothed utilization catches up and throttling kicks in.
The Capacity Metrics app shows both the raw utilization (which may spike above the limit) and the smoothed utilization (which reflects what Fabric's throttling engine actually acts on). Reading only the raw line will produce false alarms; reading only the smoothed line will understate peak consumption. A useful reading posture is to monitor the smoothed line for throttling thresholds and the raw line for identifying which workload types are driving spikes.
The burndown chart
The app includes a burndown chart that shows the accumulated CU debt — how much excess CU has been consumed beyond the capacity allocation, and how long it will take to burn down at the current usage rate. A large accumulated debt means background operations will face sustained throttling until the debt clears. This is the clearest signal that a capacity is undersized or that a specific workload needs to be scheduled differently.
For day-to-day operations, the burndown chart is more actionable than the raw utilization chart because it directly forecasts the duration of any current throttling event.
What the Capacity Metrics app does not show
The Fabric Capacity Metrics app is built for capacity management, not pipeline operations. There are several categories of information that capacity administrators commonly look for that it does not provide.
Individual job outcomes
The app shows that a Fabric pipeline consumed X CU seconds during a time window. It does not show whether that pipeline succeeded or failed. A pipeline that ran for 20 minutes and then failed consumes CU through its entire run — the CU line goes up, then stops. Without checking the pipeline run history in the Fabric portal separately, you cannot determine from the Capacity Metrics app whether a workload completed successfully.
Failure root causes
When a semantic model refresh fails, it appears in the Capacity Metrics app as a workload that stopped consuming CU. The reason for the failure — a connection error, a timeout, a schema change in the source — is not surfaced in the capacity view. The Monitoring Hub within the Fabric portal provides run status for pipelines and dataflows, but it is workspace-scoped rather than capacity-scoped, and it requires navigating to each workspace individually.
Downstream BI impact
If a Fabric dataflow fails at 04:00 AM and a Power BI semantic model that depends on it refreshes at 05:00 AM, the semantic model either fails or loads stale data. The Capacity Metrics app shows both workloads consuming CU in their respective windows. It does not surface the dependency between them or the fact that the semantic model is now serving data from the previous successful run.
Alert routing
The Capacity Metrics app is a read-only report. It has no built-in alerting mechanism. Capacity administrators who want proactive notification of throttling events or CU overages need to build custom alerting on top of the Fabric REST API or use a third-party monitoring tool.
This is the gap where dedicated monitoring tools like MetricSign operate: they watch the pipeline and refresh outcomes that the Capacity Metrics app does not surface, and send alerts when something breaks — without requiring the administrator to open the app and look.
Common scenarios where the Capacity Metrics app misleads teams
Teams that rely solely on the Fabric Capacity Metrics app for operations monitoring encounter a predictable set of situations where the capacity data looks healthy while something is broken.
The low-CU failed pipeline
A Fabric pipeline that fails immediately — within the first 30 seconds of execution — consumes very little CU. On the Capacity Metrics app, a failed pipeline looks identical to a pipeline that was never scheduled. The CU line does not spike. There is no anomaly to investigate. The only signal is in the pipeline run history, which the Capacity Metrics app does not display. Teams monitoring capacity health and seeing a quiet CU chart will miss this failure entirely.
The throttled-but-succeeded workload
The inverse scenario: a Fabric pipeline runs during a period of high capacity utilization, gets throttled by the smoothing mechanism, takes 3x its normal duration, but eventually completes. The Capacity Metrics app shows a throttling event. A team monitoring CU health will investigate the capacity spike. But the pipeline succeeded — the business impact was a delayed refresh, not a failed one. Without pipeline duration monitoring, the team treats every throttling event as an incident, even when the workload completed within its acceptable window.
The zero-impact capacity spike
A Fabric Spark notebook runs an exploratory analysis that consumes a large amount of CU but has no downstream effect on production semantic models. The Capacity Metrics app shows a significant spike. Teams without item-level attribution will investigate the spike without knowing it came from a non-production workload. The Capacity Metrics app does show CU breakdown by workspace and item, but linking a spike to a specific job type requires drilling through multiple tabs.
Silent dataflow failures and stale semantic models
A Fabric dataflow Gen2 fails partway through its run. It consumed CU up to the point of failure, which appears in the Capacity Metrics app as normal background operation CU. The downstream semantic model refresh runs as scheduled and successfully loads the data the dataflow wrote before it failed — which is partial. The Capacity Metrics app shows a successful refresh (normal CU consumption for a semantic model refresh). The data is incomplete. There is nothing in the capacity view to indicate the problem.
How MetricSign complements the Fabric Capacity Metrics app
MetricSign and the Fabric Capacity Metrics app answer different questions. The Capacity Metrics app answers: does my capacity have headroom, and is throttling affecting my workloads? MetricSign answers: which pipelines failed, which semantic models are serving stale data, and what caused the failure?
MetricSign connects to the Fabric REST API and monitors pipeline run status, dataflow Gen2 refresh outcomes, and semantic model refresh history. When a pipeline fails, MetricSign creates an incident with the pipeline name, run ID, and error detail. When a dataflow fails and the downstream semantic model refreshes against incomplete data, MetricSign surfaces both events in a single incident view with the dependency between them visible.
What MetricSign monitors in Fabric
Fabric Data Pipeline runs: MetricSign polls pipeline run status and creates incidents for both job_failed (pipeline run returned a failed state) and job_slow (pipeline run exceeded its historical duration baseline). Duration baselines use median absolute deviation over the trailing run history, so slow-run detection adapts to workloads that naturally grow over time.
Fabric dataflow Gen2 refreshes: dataflow failures are surfaced as incidents with the dataflow name and workspace. If the dataflow feeds a semantic model that is also monitored, the dependency is shown in the incident chain.
Semantic model refreshes: MetricSign monitors refresh status for all connected semantic models and classifies failures by error code. A refresh that fails because the upstream dataflow wrote incomplete data is correlated with the dataflow failure in the same incident timeline.
Alert routing
MetricSign routes alerts via email, Teams webhook, Telegram, or generic webhook. Alerts include the specific item name, workspace, run ID, and error detail — so the on-call engineer can act immediately without opening the Fabric portal.
For teams running Fabric alongside Power BI, ADF, or Databricks, MetricSign provides a single incident feed spanning all connected tools. A Databricks job failure that delays a Fabric pipeline that delays a semantic model refresh appears as one correlated incident chain, not three separate alerts from three separate tools.
Sizing decisions: using Capacity Metrics to right-size your Fabric capacity
The Fabric Capacity Metrics app is the right tool for capacity planning and right-sizing decisions. Understanding how to read it for this purpose is distinct from using it for operations monitoring.
Identifying over-utilization patterns
A capacity that regularly hits its CU limit during the morning batch window — typically between 05:00 and 08:00 UTC when scheduled refreshes run — is a candidate for either a capacity upgrade or workload rescheduling. The Capacity Metrics app's time-of-day heatmap shows which hours consistently push the capacity toward its limit. If peak utilization is consistently above 80% of the smoothed allocation during the batch window, and important workloads are being throttled (visible as longer-than-expected run times), the capacity is undersized for the scheduled workload.
Identifying wasted capacity
The inverse of over-utilization is under-utilization: a capacity that sits below 20% of its allocation for most of the day is over-provisioned for the current workload. The Capacity Metrics app's daily and weekly average views help identify whether capacity spikes are brief (suggesting the current SKU is appropriate if the peaks don't cause throttling) or whether the base load is simply low.
Evaluating the impact of scaling
Fabric capacities can be paused and resumed, and SKU size can be changed. The Capacity Metrics app is useful for evaluating the before-and-after effect of a SKU change: compare the smoothed utilization curves from the week before the upgrade to the week after. If the burndown debt is significantly lower and throttling events have disappeared, the upgrade was appropriately sized.
What capacity metrics cannot tell you about scaling
Capacity metrics do not tell you whether a workload that runs within CU limits is completing correctly. A capacity upgrade that eliminates throttling will also eliminate slow-run incidents caused by throttling — but if a pipeline is failing for a non-throttling reason (connection error, authentication failure), the failure persists regardless of capacity size. Before attributing failures to capacity constraints, verify with pipeline run history that the workloads are actually being throttled rather than failing for other reasons.