The Microsoft Fabric Capacity Metrics App: A Complete Guide
By Jonathan Flach · Published 2026-06-20 · Reviewed 2026-06-20
An F64 capacity running at full utilization costs $8,409.60 per month (64 CUs × $0.18/CU-hour × 730 hours, as of June 2026 PAYG). The Microsoft Fabric Capacity Metrics app is the free, first-line tool that tells you whether you are buying the right amount of that compute, what is consuming it, and when you are about to overspend. But the app is not a flight recorder — it keeps 14 days of compute detail and 30 days of storage, and its data lags 10–15 minutes behind live activity. Understanding every page of the app — what it shows, what it measures, and where it stops — is the baseline skill every Fabric capacity admin needs. For the broader native-vs-gap picture, see the Microsoft Fabric Capacity Monitoring guide.
The Capacity Metrics app is a Power BI app installed by a capacity admin from AppSource. A capacity admin is the only role that can install and share it. Once installed, it creates a workspace in your Fabric tenant and lands a semantic model that pulls data from your capacity's telemetry. The app currently has twelve pages (Item History, added in preview August 2025, is the twelfth); this walkthrough covers the seven core operational pages most capacity admins use daily: Health, Compute, Storage, Timepoint, Timepoint Summary, Timepoint Item Detail, and Item History (preview, August 2025). The two Autoscale compute for Spark pages are covered separately. Each answers a different question.
The annotated page-by-page walkthrough
This is the original material for this article — a structured map of what each page shows, what its controls do, what its limits are, and what it cannot tell you. No Microsoft documentation page covers all pages end-to-end in this format.
Health page
The Health page is the multi-capacity dashboard. If you admin more than one capacity, this is where you start. It shows two time views — Last 24 hours and Last one hour — and surfaces the following cards for every capacity you have admin access to (Microsoft Learn, Understand the metrics app Health page, checked June 2026):
- # Capacities — total under your admin scope
- Avg. utilization % — average across selected capacities for the chosen window
- # Throttled capacities — capacities with at least one 30-second window where interactive delay % exceeded 100%
- # Interactive rejected capacities — at least one window above the interactive-rejection threshold
- # Background rejected capacities — at least one window above the background-rejection threshold
The "Last one hour" view is the nearest the app gets to real-time. It still lags 10–15 minutes. Select any capacity in the Health page breakdown and drill through to Compute or Storage for deeper analysis.
Limit: The Health page is scoped to your admin access. If you administer only one capacity in a multi-capacity tenant, you see only that one. Cross-capacity tenant rollup requires FUAM or a custom extract.
Compute page
The Compute page is the operational core — the primary tool for sizing, throttling diagnosis, and workload investigation. It shows data for the last 14 days (Microsoft Learn, Understand the metrics app compute page, checked June 2026).
Three cards sit at the top: SKU (current), Average utilization %, and Peak utilization %, all filtered by your capacity and date range selection.
Below the cards are three visual sections:
Multimetric ribbon chart — An hourly stacked bar showing the top-consuming items across CU, Duration, Operations, and Users for the past two weeks. Switching between the four metrics re-ranks the ribbon. Selecting a column or item segment cross-filters the utilization chart and the matrix table below.
Capacity utilization and throttling chart — This is the visual most admins spend the most time in. It has four tabs:
| Tab | What it shows |
|---|---|
| Utilization | Blue (background %) and red (interactive %) columns per 30-second timepoint against the SKU's CU% limit line. Columns above the line are overload timepoints. |
| Throttling | Future-capacity debt as a percentage of the four thresholds (see the Throttling section below). |
| Overages (Carryforward) | Add %, burndown %, and cumulative % of carryforward debt at each timepoint. |
| Overages (Billed) | Populated only if capacity overage is enabled; shows billed overage CU-seconds and the rolling 24-hour overage against the billing limit. |
Matrix by item — The bottom table ranks every item (pipeline, notebook, semantic model, dataflow) by CU for the selected time range. Hovering a row shows a tooltip with the breakdown by operation type (query vs. refresh) — one of the few places in the app where you can see that granular split.
Filter granularity: By default, the utilization chart shows the peak timepoint every six minutes to keep the chart readable. Once you apply a filter (selecting a date in the ribbon, or a row in the matrix), the chart resolves to every 30-second timepoint. Select a column then click Explore to drill into the Timepoint detail page for that specific window.
Throttling tab (within the Compute page)
The Throttling tab deserves its own callout because it is widely misread. Throttling in Fabric is not a utilization percentage — it is a future-capacity consumption measured in time windows. The four thresholds (Microsoft Learn, Metrics app compute page, checked June 2026):
| Threshold | Future-usage debt crossed | User experience |
|---|---|---|
| Overage protection | Up to 10 minutes | No impact — burst absorbed |
| Interactive delay | 10–60 minutes | New interactive requests get a ~20-second hold |
| Interactive rejection | 60 minutes–24 hours | New interactive requests refused; users see errors |
| Background rejection | Over 24 hours | All new requests refused — both interactive and background (full capacity shutdown) |
A bar at 75% of the interactive-rejection chart means you have used 45 minutes of the 60-minute window — 15 minutes of headroom remain before interactive rejection begins. On the interactive-delay chart (a 10-minute future-capacity window), 75% means 7.5 minutes of future-capacity debt and a 20-second throttle is already being applied to interactive requests (Microsoft Learn, Understand the metrics app compute page and Metrics app calculations, checked June 2026). That is the reading the chart demands: headroom in future-capacity time, not headroom in instantaneous utilization. For the full mechanics, see Fabric throttling explained.
Timepoint page
The Timepoint page is the forensics view. You reach it by selecting a column on the Compute page and clicking Explore. It shows every operation (interactive and background) that was active in that specific 30-second window, ranked by CU impact (Microsoft Learn, Understand the metrics app timepoint page, checked June 2026).
This is where you find which item caused a spike. The matrix shows item name, workspace, operation, user (if the admin setting allows), CU-seconds consumed, and duration. From here you can drill further into the Timepoint item detail page for granular operations within a specific item in that window — filters include operation ID, user, and CU thresholds.
Attribution limit: The Timepoint page shows which item consumed CUs. It does not link the OperationID to a specific pipeline run, notebook execution, or scheduler trigger. Closing that gap requires joining to the Activity Events admin API in an external store — the item-level ceiling is structural, not a missing feature.
Storage page
The Storage page tracks OneLake storage over the past 30 days (Microsoft Learn, Understand the metrics app storage page, checked June 2026).
Cards show total workspaces using storage, current storage (GB), and billable storage (GB). Note: soft-deleted data is billed at the same rate as active data, so billable storage can differ from current storage when deletions are recent.
The table ranks top workspaces by billable storage %, showing current GB, billable GB, deletion status, and billing type per workspace. Use the Top N slicer to widen or narrow the list.
Storage limit: The 30-day window is the full native window. There is no archive. If a workspace is deleted, its storage history disappears from the app.
Item History page (preview)
As of August 2025, the app gained an Item History page in preview. It provides a 30-day compute history at the workspace and item level — longer than the Compute page's 14-day window, but with less granularity (no 30-second timepoint drill-through). It is the bridge between the 14-day operational view and the long-term history you would otherwise need an external extract to get. Per Microsoft Learn (What's New? — August 2025, checked June 2026), it provides "interactive visuals and slicers for workspace and item-level analysis."
Limits callout: what the app cannot do
Data latency: Usage data becomes available 10–15 minutes after the activity occurs. At 5:15 PM, charts may show data only up to approximately 5:00 PM.
Dimension refresh: New capacities, workspaces, and items appear in the app after the next nightly refresh at midnight local time. A workspace created at 3 PM will not appear by name until the following morning.
Compute retention: The Compute page is a rolling 14-day window. Day 15 drops off as a new day rolls in. No native archive, no export, no extension.
Storage retention: The Storage page is a rolling 30-day window.
No alerts: The app has no alerting engine. Discovering throttling requires opening the app after the fact. For proactive alerts, use Fabric capacity overview events in the Real-Time hub.
Attribution ceiling: Attribution is item-level. OperationID is not linked to pipeline runs. User data can be masked by admin setting.
No cross-capacity rollup: Each app install is scoped to the capacities in your admin role. Tenant-wide rollup is not native.
These limits are not defects — they reflect the tool's design as a real-time operational gauge, not a long-term record. The retention wall and attribution ceiling are the foundation of the Fabric metrics retention limit and Fabric throttling explained articles, which go deeper on each.
The named enemy: the metrics-retention wall
The Capacity Metrics app is the right tool for the job it is built for — real-time triage and short-term capacity sizing. Its 14-day compute window is the hard boundary that turns it from a complete monitoring solution into a starting point.
The practical failure modes are predictable. A capacity throttles on a Tuesday afternoon. You open the app Wednesday evening. The spike is still visible — but you need to compare it to the same Tuesday four weeks ago to tell whether this is getting worse or is a one-off. The app cannot make that comparison. Month-over-month trend, quarterly chargeback reconciliation, "did we make progress after that Spark query tuning session?" — none of these are answerable from the Compute page beyond 14 days.
The fix is always the same shape: extract before day 15. Schedule a SemPy notebook or a Power BI executeQueries API call (one query per request, 100k-row cap) to pull the metrics model data and append it to a lakehouse you own. That external store becomes the long-term record the app cannot be. The extraction mechanics and the DAX to use are in the Fabric metrics retention limit.
What to do in the app right now
- Install the app if you have not already — you must be a capacity admin. Install from AppSource or your Power BI admin's app gallery.
- Open the Health page first. Scan the throttling and rejection cards for the last 24 hours. Any non-zero throttled-capacity count warrants investigation before you open anything else.
- Go to the Compute page and set the date range to the last 14 days. Check peak utilization. Anything consistently above 70% average should trigger a sizing conversation.
- Click the Throttling tab. If you see bars near or above 100% of interactive delay, find which item is driving it by selecting that column and exploring the Timepoint detail.
- Read the matrix by item. Sort by CU descending. The top five items are your cost concentration. If one item owns more than 40% of your capacity, that is your first optimization target.
- Check the Storage page. Billable storage significantly higher than current storage means you have soft-deleted data still billing — clean up or relocate before the month closes.
- Schedule your first metrics extract. Set a SemPy notebook on a nightly schedule to pull from the Capacity Metrics semantic model before day 15 closes the window.
The Capacity Metrics app is genuinely good at what it does. Its 14-day compute window and 10–15 minute data lag are facts of the tool's design, not reasons to avoid it — they are reasons to complement it. Use it daily for triage and throttling diagnosis, pair it with the Real-Time hub events for alerting, and extract it nightly to build the long-term record it cannot maintain.
Frequently asked questions
What is the Microsoft Fabric Capacity Metrics app? The Microsoft Fabric Capacity Metrics app is a free Power BI app that capacity admins install to monitor CU consumption, throttling, and storage across their Fabric capacities. Its Compute page shows 14 days of compute detail per Microsoft Learn; its Storage page shows 30 days. Data lags 10–15 minutes behind live activity, and dimension data (new workspaces, capacities, items) refreshes nightly at midnight local time.
How do I read the Capacity Metrics app Compute page? The Compute page shows a 14-day ribbon chart (top-consuming items), a utilization-and-throttling chart, and a matrix-by-item table. The ribbon chart stacks items by CU in each hour. The utilization chart shows blue (background %) and red (interactive %) columns against the SKU's CU% limit line — anything above that line is an overload. The throttling tab on the same visual shows whether future-capacity debt has crossed the interactive-delay, interactive-rejection, or background-rejection thresholds. Drill into any column with the Explore button to reach the Timepoint detail page for that 30-second window.
How long does the Fabric Capacity Metrics app keep data? Compute detail: 14 days on the Compute page. Storage data: 30 days on the Storage page. The Item History page (preview, as of August 2025) extends compute history to 30 days at the workspace and item level. There is no native way to extend the Compute page beyond 14 days — extract the data via SemPy or the Power BI executeQueries API before the window closes.
What does the throttling tab in the Capacity Metrics app show? The Throttling tab shows future-capacity consumption as a percentage of the four smoothing thresholds: overage protection (up to 10 minutes), interactive delay (10–60 minutes), interactive rejection (60 minutes–24 hours), and background rejection (over 24 hours). Each bar represents a 30-second timepoint. A bar above 100% means that threshold has been crossed — interactive delay means a 20-second hold on report renders; interactive rejection means new interactive requests are refused; background rejection means all new requests are refused — both interactive and background jobs.
Can the Capacity Metrics app tell me which pipeline run caused a spike? No. Attribution in Fabric is item-level: the app shows which pipeline item burned CUs, but it does not link a capacity-event OperationID back to an individual pipeline run. The Timepoint item detail page narrows it to operations within a specific item at a specific 30-second window, but connecting that to the exact scheduler trigger or user requires joining to the Activity Events admin API in an external store.
Researched with AI assistance, written and fact-checked by Jonathan Flach, verified against Microsoft Learn.