Microsoft Fabric Capacity Metrics App: Every Page Explained — Health, Compute, Storage, Timepoint, Item History, Autoscale, Throttling, Smoothing, and the Chargeback App
Our Administration & Cost post covered capacity fundamentals — what CUs are, how SKUs map to CU counts, and how throttling works at a high level. This post goes hands-on with the Capacity Metrics App itself: the prebuilt Power BI report that Microsoft provides for monitoring everything happening inside your Fabric capacity. We walk through every page, every visual, every metric — so you know exactly what to look at when your capacity is overloaded, when dashboards are slow, or when the CFO asks why the Fabric bill went up.
Analogy — The flight dashboard of an airplane. A pilot does not fly by looking out the window and guessing fuel levels. The cockpit has dedicated gauges for altitude, speed, fuel, engine temperature, and dozens of warning indicators. The Capacity Metrics App is the cockpit of your Fabric capacity. The Health page is the overview panel — green lights mean everything is fine, red lights mean investigate. The Compute page is the engine monitor — how hard the engines are working. The Storage page is the fuel gauge — how much data you are carrying. The Timepoint pages are the black box recorder — what happened at a specific moment when something went wrong.
What Are Capacity Units (CUs)?
Before diving into the app, you need to understand the currency it measures. Every operation in Fabric — running a notebook, refreshing a semantic model, executing a warehouse query, loading data in a pipeline — consumes Capacity Units (CUs). A CU is a normalized measure of compute power. Your capacity’s SKU determines how many CUs you get per 30-second window.
Think of CUs like electricity in a building. Your electrical panel (SKU) has a maximum amperage rating. Every appliance (Fabric workload) draws power. If all appliances run simultaneously and exceed the panel’s rating, the breaker trips (throttling). The Capacity Metrics App shows you which appliances are drawing how much power, when the panel is near capacity, and what tripped the breaker.
| SKU | CUs per 30 seconds | Typical Use Case |
|---|---|---|
| F2 | 2 | Dev/test, individual exploration |
| F4 | 4 | Small team, light workloads |
| F8 | 8 | Department-level analytics |
| F16 | 16 | Production workloads, multiple teams |
| F32 | 32 | Enterprise workloads with heavy Spark |
| F64 | 64 | Large-scale production, many concurrent users |
| F128 | 128 | Enterprise-wide platform |
| F256+ | 256+ | Global deployments, heavy real-time workloads |
Interactive vs background operations: Fabric classifies every operation as either interactive (user-triggered, needs a fast response — dashboard queries, SQL queries, notebook cell runs) or background (system-triggered, can tolerate delay — dataset refreshes, pipeline runs, Spark jobs). This distinction matters because throttling applies differently: interactive operations get delayed first, then rejected. Background operations get smoothed over a longer window before facing throttling.
How to Install the Capacity Metrics App
The app is a free Power BI template app from Microsoft AppSource. You need a Power BI Pro license (or PPU) and capacity admin permissions to install it.
Step 1: Go to the Fabric portal. In the left nav, click Apps and then Get apps in the top-right corner.
Step 2: In the AppSource search box, type Microsoft Fabric Capacity Metrics and select the app from the results.
Step 3: Click Get it now. Sign in with your Microsoft account if prompted and complete the registration screen.
Step 4: You are redirected back to Fabric. Click Install to add the app to your workspace.
Step 5: Once installed, open the app. Use the Capacity Name dropdown at the top of every page to select which capacity you want to monitor.
Important installation tips: Install the app in a workspace backed by a Pro license, not in your Fabric capacity workspace — otherwise the app’s own queries consume CUs from the capacity you are trying to monitor. If you are upgrading from an older version, install the latest version from AppSource; the upgrade preserves your existing workspace.
App Pages Overview
The Capacity Metrics App contains the following pages, each designed for a different monitoring depth:
| Page | What It Shows | Retention | When to Use |
|---|---|---|---|
| **Health** | At-a-glance status of all capacities you admin | Last 24 hours / last 1 hour | Daily health check, capacity overview across regions |
| **Compute** | CU consumption trends, throttling, operations matrix | Last 14 days | Weekly review, identifying peak utilization patterns |
| **Storage** | OneLake storage by workspace and experience | Last 30 days | Monthly cost review, identifying storage growth |
| **Timepoint** | 30-second drill-down of interactive and background CUs | Specific moment | Diagnosing a throttling event or overload |
| **Timepoint Summary** | Summarized operation types at a timepoint | Specific moment | Understanding which operation categories drove an overload |
| **Timepoint Item Detail** | Granular detail on operations within a specific item | Specific moment | Root-cause analysis of a specific item’s consumption |
| **Item History** (Preview) | 30-day compute usage trends per item | Last 30 days | Identifying consistently expensive items over time |
| **Autoscale Compute for Spark** | Spark autoscale billing overview | Last 14 days | Monitoring Spark-specific autoscale consumption |
| **Autoscale Compute for Spark Detail** | Drill-down into specific Spark autoscale timepoints | Specific moment | Diagnosing which Spark jobs triggered autoscale |
The Health Page
The Health page is the starting point for any capacity admin. It shows a single-screen summary of all Fabric capacities you administer, grouped by region. Think of it as the reception desk of a hospital — you see the status of every patient (capacity) at a glance: who is healthy, who is under stress, and who needs immediate attention.
Key visuals on the Health page:
Capacity breakdown table — One row per capacity showing SKU, region, average utilization, 95th percentile values for interactive delay, interactive rejection, and background rejection. Color coding: green means healthy, orange means moderate stress, red means throttling has occurred. You can select a row and drill through to the Compute or Storage pages for that capacity.
Time toggle — Switch between “Last 24 hours” and “Last 1 hour” for different granularity. Use “Last 1 hour” for real-time monitoring during an incident. Use “Last 24 hours” for the daily health check.
Blocked workspaces count — If a workspace has been blocked (operations rejected due to persistent overload), it appears here. This is your most urgent alert — a blocked workspace means users are unable to run any interactive queries in that workspace.
Sparkline visuals — Toggle between sparkline (trend lines embedded in the table) and static values. Sparklines help you spot trends — a capacity that is gradually climbing toward its limit will show a rising sparkline.
The Compute Page
The Compute page is the heart of the app. It provides a 14-day view of how CUs are being consumed across your capacity. This is where you spend most of your monitoring time.
Multi-metric ribbon chart — The main visual at the top. Each column represents a time interval (6-minute peak when no filters applied, 30-second granularity when filtered). The columns are stacked by experience (Data Engineering, Data Warehouse, Power BI, etc.). Two dotted lines mark your limits: the grey CU % Limit line shows your base capacity, and the orange Autoscale CU % Limit shows the extended limit if autoscale is enabled. When columns exceed the grey line, your capacity is overloaded.
Throttling chart — Below the ribbon chart, this shows delay and rejection over time. You see three throttling stages visually: – Interactive delay — Operations are queued and slowed down. This is the first warning sign. – Interactive rejection — Operations are actively rejected. Users see errors. This is serious. – Background rejection — Background jobs (pipeline runs, refreshes) are rejected. This means your capacity is severely overloaded.
Operations matrix — A table at the bottom showing every item in the capacity, sorted by CU consumption. Columns include item name, workspace, operation count, CU seconds, duration, and performance delta. The performance delta uses color coding: no color means normal, orange means degraded (between -10% and -25%), red means severely degraded (below -25%). Sort by CU seconds to find your most expensive items immediately.
AI Functions operation group — A dedicated operation category in the ribbon chart and matrix that separates AI Functions usage from Spark and Dataflows Gen2, so you can see how much AI consumption is contributing to your capacity.
The Storage Page
The Storage page provides a 30-day view of how much OneLake storage your capacity is consuming. Storage is billed separately from compute, so this page helps you understand your storage cost trajectory.
Key visuals:
Storage cards — Three cards at the top showing current billable storage, current non-billable storage, and total storage. Billable storage is what you pay for. Non-billable includes data that is in a free tier or covered by your SKU’s included storage.
Storage trend chart — A column chart showing daily storage over the last 30 days. A steadily rising chart means you need to review retention policies or archive old data. A sudden jump means a large data load or a table without retention.
Workspace storage table — Breaks down storage by workspace and experience. Sort by storage size to find which workspaces are consuming the most. Includes a column for soft-deleted data — data that has been deleted but not yet purged (Delta Lake retains deleted files for time travel until VACUUM runs).
Filters — Filter by capacity name, date range, experience (Data Engineering, Data Warehouse, etc.), and storage type. Use the experience filter to isolate Lakehouse storage from Warehouse storage to understand which layer is growing fastest.
Timepoint Pages (Drill-Down Diagnostics)
The Timepoint pages are your forensic investigation tools. When the Compute page shows an overload event, you drill into a specific 30-second timepoint to see exactly what was consuming CUs at that moment.
Timepoint Page
The Timepoint page shows the operations that contributed to CU consumption during a specific 30-second window. You get here by selecting a column in the Compute page’s ribbon chart and clicking Explore.
Heartbeat line chart — A 60-minute window of CU activity centered on the selected timepoint (30 minutes before and 30 minutes after). The vertical green line marks the exact timepoint. Use this to see whether the overload was a spike (one-time) or sustained (long plateau).
Interactive and background cards — Show the total number of interactive and background operations in this timepoint. If interactive operations are unusually high, a user or dashboard triggered a burst of queries.
CU breakdown — Shows how much of the 30-second CU allowance was consumed. If the total exceeds 100%, the capacity was overloaded. The breakdown separates: – Green — Normal CU consumption – Red — Consumption exceeding the CU limit – Yellow — Consumption covered by autoscale (if enabled)
Timepoint Summary Page
Instead of individual operations, this page summarizes operation types that contributed to usage during the selected timepoint. Toggle between interactive and background views. This tells you whether the overload came from Power BI queries, Spark jobs, pipeline activities, or AI Functions — without listing every individual operation.
Timepoint Item Detail Page
The most granular page. It shows individual operations for a specific item at the selected timepoint. Filters include operation ID, user, and CU thresholds. Use this for root-cause analysis: “Which specific notebook run by which user consumed 40% of capacity at 2:15 PM?”
The Item History Page (Preview)
The Item History page provides a 30-day compute usage analysis with slicers and dynamic visuals. Unlike the Compute page (which shows all items aggregated), the Item History page focuses on individual item trends over time.
Key slicers: Capacity name, workspace, experience, operation, run by (user), and billing type.
Key visuals:
CU(s) by workspace — Shows which workspaces are consuming the most CUs over time. Filter to identify workspaces that are disproportionately expensive.
CU(s) by item — Drills down to individual items. Find the specific notebook, pipeline, or semantic model that is consuming the most capacity over 30 days.
Smoothed CU% over time — A line chart that shows smoothed CU consumption with the CU % limit line. Toggle between background and interactive to see if interactive operations are driving overloads.
Workspace details table — Aggregated workspace-level metrics including operations pass rate (percentage of operations that completed successfully), number of operations, and percentage of total compute consumed.
Autoscale Compute for Spark Pages
These two pages are specific to capacities that have Spark autoscale billing enabled. Standard Fabric autoscale adds CUs to the base capacity when demand exceeds the limit. Spark autoscale is a separate billing model where Spark jobs can burst beyond the capacity limit and are billed per-CU at a pay-as-you-go rate.
Autoscale Compute for Spark Page
Shows an overview of Spark autoscale consumption over 14 days. The ribbon chart uses 1-minute granularity (finer than the standard Compute page’s 30-second timepoints). A dotted line marks the Max CU Limit 1 Minute — the autoscale ceiling. The matrix table shows which items consumed the most Spark autoscale CUs. Spark autoscale data is not smoothed — you see raw consumption, making it easier to identify bursty Spark jobs.
Autoscale Compute for Spark Detail Page
Drill into a specific 1-minute timepoint. Shows a heartbeat chart (60-minute window), CU seconds consumed, total Spark operations, and a table of the top 100,000 records ranked by CU consumption. Use this when investigating why a specific Spark job triggered autoscale billing.
Understanding Smoothing and Throttling
Smoothing is how Fabric spreads the cost of an operation over time. When a background Spark job runs and consumes a large burst of CUs in 10 seconds, Fabric does not charge the entire burst to that single 30-second timepoint. Instead, it “smooths” the consumption over a longer window (typically 24 hours for background operations, 5 minutes for interactive). This prevents a single large job from triggering throttling immediately.
Think of smoothing like a credit card payment plan. You bought a $12,000 appliance (expensive Spark job). Instead of paying $12,000 this month (immediate CU charge), the credit card company spreads it across 12 months at $1,000/month (smoothed consumption). Your monthly budget (CU limit) stays manageable — but the debt (future CU commitment) accumulates.
The risk of smoothing: If you run many large background jobs, the smoothed consumption from past jobs accumulates. Even though no single job exceeded your limit, the combined smoothed consumption can push your capacity over 100% in future timepoints. This is why the Compute page can show overload even when you are not running anything at that moment — it is repaying smoothed CU debt from earlier jobs.
Throttling stages — When total CU consumption (smoothed + current) exceeds 100%:
| Stage | Threshold | What Happens | User Impact |
|---|---|---|---|
| **Interactive delay** | >100% | Interactive operations are queued and delayed | Dashboards load slowly, queries take longer |
| **Interactive rejection** | >200% sustained | Interactive operations are rejected outright | Users see error messages, dashboards fail to load |
| **Background rejection** | >300% sustained | Background operations are also rejected | Pipeline runs fail, refreshes are cancelled |
Autoscale as a safety valve: If autoscale is enabled, Fabric adds CUs to handle the burst instead of throttling. Each additional CU stays active for 24 hours and is billed at pay-as-you-go rates. The Compute page shows autoscale CUs as a yellow band above the base capacity limit line.
The Chargeback App
The Microsoft Fabric Chargeback App is a separate Power BI template app (also from AppSource) that helps you allocate Fabric costs to business units, teams, or departments based on actual consumption. While the Capacity Metrics App tells you what is consuming CUs, the Chargeback App tells you who should pay for it.
Key features:
Workspace-level cost breakdown — Shows what percentage of your capacity was consumed by each workspace. If your Finance workspace consumed 30% and your Marketing workspace consumed 45%, you can charge each department proportionally.
Item-level cost breakdown — Drills down to individual items. The specific pipeline or notebook driving costs is identified by name.
Domain/subdomain breakdown — If you have organized workspaces into Fabric domains, the Chargeback App aggregates costs by domain and subdomain. Items not assigned to a domain appear under “No domain.”
Export capabilities — Data can be exported for integration with your organization’s finance systems.
Refreshed daily — The data is not real-time. It refreshes once per day. You can trigger a manual refresh from the workspace where the app is installed.
DP-700 exam tip: Know the difference between the Capacity Metrics App (monitoring — what is consuming CUs and when) and the Chargeback App (cost allocation — who should pay). The Capacity Metrics App is for capacity admins diagnosing performance. The Chargeback App is for finance and management allocating costs.
Real-World Diagnostic Scenarios
Scenario 1: Dashboard loads slowly after 2 PM every day
Open the Compute page and filter to the last 7 days. Look at the ribbon chart — do you see a pattern where CU consumption spikes every afternoon? Drill into a 2 PM timepoint. Check the operations matrix — a scheduled pipeline refresh at 2 PM might be consuming so many CUs that interactive operations (dashboard queries) are delayed. Solution: reschedule the pipeline to run at a low-usage window (midnight) or stagger the refresh across multiple time slots.
Scenario 2: Sudden spike in Fabric bill
Open the Chargeback App and filter to the billing period. Sort by item-level consumption. A new Spark notebook that a data scientist added last week might be running every hour and consuming more CUs than the rest of the capacity combined. Cross-reference with the Capacity Metrics App’s Item History page to see the 30-day trend. Solution: optimize the notebook, change the schedule from hourly to daily, or move it to a dedicated capacity.
Scenario 3: Users report “Request could not be completed” errors
This is interactive rejection — the most severe throttling stage. Open the Compute page and find the time when errors occurred. The throttling chart will show a red spike in interactive rejection. Drill into the timepoint. The operations matrix shows which items consumed the most CUs. Often the culprit is a combination of: a large Spark job smoothing its CU debt from the previous night plus a burst of dashboard queries in the morning. Solution: enable autoscale as a short-term fix, reduce the size of the background Spark job, or scale up the capacity SKU.
Scenario 4: Storage costs are growing 10% per month
Open the Storage page. Sort the workspace storage table by size. A Lakehouse with no retention policy might be accumulating raw ingestion files indefinitely. Check for soft-deleted data — Delta Lake retains deleted files until VACUUM runs. Solution: run VACUUM on Delta tables, set shorter retention on Eventhouse tables, and archive historical data to ADLS Gen2 via shortcuts.
Common Mistakes
1. Installing the app in the monitored capacity’s workspace. The app itself runs Power BI queries. If those queries consume CUs from the capacity you are monitoring, you are both inflating your metrics and potentially contributing to throttling. Install the app in a workspace backed by a Pro license instead.
2. Only checking the Compute page during incidents. By the time users report errors, the overload may have subsided and the evidence has shifted in the 14-day window. Check the Health page daily (1-minute check) and review the Compute page weekly (10-minute review) to catch trends before they become incidents.
3. Ignoring smoothed consumption. The Compute page can show your capacity at 80% utilization even when nothing is currently running — because smoothed background consumption from past jobs is being “repaid.” Understanding smoothing is essential to diagnosing throttling that seems to happen “for no reason.”
4. Not using the Timepoint drill-down. The Compute page shows aggregated trends. The Timepoint page shows exact operations at a specific 30-second moment. Diagnosing throttling requires the Timepoint page — the Compute page alone is not granular enough.
5. Confusing the Capacity Metrics App with the Chargeback App. The Metrics App is for performance monitoring (what is consuming CUs and when). The Chargeback App is for cost allocation (who should pay). Using the Metrics App for chargeback is imprecise — the Chargeback App has the right aggregations and export capabilities for finance teams.
6. Setting autoscale without monitoring it. Autoscale prevents throttling but increases cost. If you enable autoscale and never check the Autoscale Compute for Spark pages, a runaway Spark job can add CUs indefinitely. Monitor autoscale usage weekly and set alerts for autoscale CU thresholds.
7. Not filtering by experience type. The default view shows all workloads combined. A spike in CU consumption might come entirely from one experience (e.g., Data Engineering). Use the experience filter on the Compute page and the Item History page to isolate which workload category is driving the spike.
8. Treating the operations matrix as static. The matrix shows 14-day aggregated data. An item that consumed 50% of CUs on one day and 0% on the other 13 days looks small in the aggregate. Sort by peak CU consumption, not just total, and drill into specific days to find bursty items.
Interview Questions
Q: What is the Microsoft Fabric Capacity Metrics App and who should use it? A: It is a prebuilt Power BI template app from AppSource that provides monitoring capabilities for Fabric capacities. It shows compute consumption (CUs), storage usage, throttling events, and per-item breakdowns. Capacity admins and platform owners use it to monitor performance, diagnose overloads, and make scaling decisions. It is separate from the Fabric admin portal — the admin portal shows tenant-level settings, while the Metrics App shows capacity-level performance telemetry.
Q: What is the difference between interactive and background operations in Fabric? A: Interactive operations are user-triggered and need fast responses — dashboard queries, SQL queries, notebook cell executions. Background operations are system-triggered and can tolerate delay — dataset refreshes, pipeline runs, Spark batch jobs. The difference matters for throttling: interactive operations are delayed first (at >100% CU), then rejected (at >200%). Background operations are smoothed over 24 hours and only rejected at >300%. Smoothing means background operations spread their CU cost over time rather than charging it all at once.
Q: How does smoothing work in Fabric capacity management? A: When a background operation consumes a burst of CUs, Fabric spreads (“smooths”) that consumption over a 24-hour window instead of charging it all in one 30-second timepoint. This prevents a single large Spark job from instantly triggering throttling. However, smoothed consumption accumulates — if you run many large background jobs, the combined smoothed debt can push your capacity over 100% in future timepoints, causing throttling even when no operations are currently running. Interactive operations use 5-minute smoothing, so their impact is felt more immediately.
Q: What are the throttling stages and how do they progress? A: Throttling progresses in three stages. First, interactive delay (>100% CU utilization) — interactive operations are queued and slow down, but still complete. Second, interactive rejection (>200% sustained) — interactive operations are rejected outright with error messages. Third, background rejection (>300% sustained) — background operations are also rejected, meaning pipeline runs fail and refreshes are cancelled. Each stage represents increasingly severe overload. Enabling autoscale prevents throttling by adding CUs at pay-as-you-go rates.
Q: What is the difference between the Capacity Metrics App and the Chargeback App? A: The Capacity Metrics App is for performance monitoring — it shows what is consuming CUs, when overloads occur, and which items are most expensive. The Chargeback App is for cost allocation — it shows what percentage of capacity each workspace, item, or domain consumed so finance teams can allocate Fabric costs to business units. The Metrics App is used by capacity admins daily. The Chargeback App is used by finance and management monthly. They are separate apps installed independently from AppSource.
Q: How would you diagnose dashboard queries that are timing out? A: First, open the Compute page and find the time window when timeouts occur. Check the throttling chart for interactive delay or rejection — if present, throttling is the cause. Drill into the Timepoint page at that moment to see which operations consumed the most CUs. Common causes: a large background Spark job smoothing its CU debt into the same window when users are querying dashboards, a semantic model refresh running concurrently, or a poorly optimized DAX query scanning too much data. Solutions include rescheduling background jobs to off-peak hours, enabling autoscale, optimizing the query, or scaling up the capacity SKU.
Q: What should a weekly capacity review look like? A: Start with the Health page — check all capacities for any red indicators or blocked workspaces (1 minute). Move to the Compute page — review the 14-day ribbon chart for utilization trends, check if any day exceeded 80% average utilization, and review the throttling chart for any delay or rejection events (5 minutes). Sort the operations matrix by CU seconds to identify the top 5 most expensive items (2 minutes). Check the Storage page for month-over-month growth (1 minute). Finally, review the Autoscale Compute for Spark page if Spark autoscale is enabled — check if any unexpected autoscale events occurred (1 minute). Total: about 10 minutes.
Wrapping Up
The Capacity Metrics App is the single most important monitoring tool for Fabric administrators. Combined with the Chargeback App for cost allocation, these two apps give you complete visibility into how your capacity is performing and who is consuming what. Make the Health page your daily dashboard, the Compute page your weekly review, and the Timepoint pages your forensic investigation tool when something goes wrong.
Related posts: – Administration & Cost – Monitoring & Troubleshooting – Optimization Guide – Spark Configuration & Performance Tuning
Naveen Vuppula is a Senior Data Engineering Consultant and app developer based in Ontario, Canada. He writes about Python, SQL, AWS, Azure, and everything data engineering at DriveDataScience.com.