Alternatives to the Capacity Metrics App for Long-Term History & Attribution

An F64 capacity costs $8,409.60 per month at PAYG rates, and the Fabric Capacity Metrics app gives you only 14 days of compute detail for that spend — a rolling window that closes automatically on day 15 with no archive, no export, and no native setting to extend it (Understand the metrics app compute page, Microsoft Learn, checked June 2026). Any question that spans more than two weeks — month-over-month CU trend, quarterly forecasting, year-end chargeback, post-incident forensics beyond the last two Tuesdays — runs straight into what the complete guide to Fabric capacity monitoring calls the metrics-retention wall. This article maps the three realistic alternatives to that wall: a SemPy/DAX extract you build and operate yourself, FUAM (the community solution accelerator), and a purpose-built vault. The build-vs-buy table below is the honest scoring most evaluations skip.

Why the 14-day wall exists and why it matters

The metrics-retention wall is not a bug or oversight — it is a deliberate design choice that keeps the Capacity Metrics semantic model (a system-managed, read-only Power BI dataset) from growing without bound. The Compute page shows the last 14 days of capacity utilization, throttling, and item-level CU consumption in 30-second timepoints. The Storage page extends to 30 days of storage data. As of August 2025 the app also has a preview Item History page that shows 30 days of item-level compute consumption with workspace and experience slicers (Understand the metrics app item history page (preview), Microsoft Learn, checked June 2026) — a genuine improvement over the main Compute page's 14-day limit. But it is still a rolling 30-day window, not a configurable archive.

The Fabric metrics retention limit dissects the mechanism. Here the practical consequence matters most: once day 15 of compute history rolls off, you cannot recover it. There is no "export all history" button. If you did not extract it before it aged out, it is gone. This is what makes the 14-day window a FinOps problem: monthly reviews, quarterly capacity forecasts, and year-end chargeback reconciliations all need data the app cannot hold.

The attribution void compounds the problem — but it matters to understand exactly where the void is. Within the 14-day compute window, the metrics app's Timepoint detail drill-through (GA May 2026) does show user and operation-level detail: User is a default column and Operation ID is an optional column, breaking down compute usage by workspace, item, operation, and user (Understand the metrics app timepoint item detail page, Microsoft Learn, checked June 2026). So "which user caused last Thursday's throttle" is answerable natively today — if last Thursday is still inside the 14-day window. The Chargeback app adds a daily-refreshed user breakdown as well (the "Utilization (CU) details" matrix shows per-user CU consumption — hover over the users column), though usernames appear as "Masked user" when the admin setting "Show user data in the Fabric Capacity Metrics app" is disabled.

The attribution void is specifically a long-term problem: once data ages off day 14, that per-user, per-operation context is permanently gone. You cannot answer "who caused last quarter's throttle" or "which team's notebook drove the spike six weeks ago" — that detail no longer exists in any native tool. So the two questions FinOps actually needs answered — "give me six months of CU trend" and "which team's job caused last quarter's throttle" — are unanswerable from native tools once the rolling window has closed.

The three realistic alternatives

Path 1 — SemPy/DAX extract (DIY vault)

The Capacity Metrics semantic model is queryable. Microsoft exposes a REST endpoint for querying semantic models (Execute Queries, Power BI REST API, Microsoft Learn, checked June 2026):

• executeQueries — row-oriented JSON, 100k-row / 1 million-value cap per call. Works on shared/Pro/PPU and Fabric capacities with Build access on the model and at least Viewer on the workspace.

From inside a Fabric notebook, SemPy's evaluate_dax function wraps the query over the Capacity Metrics semantic model without manual credential handling — it uses the notebook's runtime identity. Important caveat: Microsoft explicitly marks the Capacity Metrics semantic model as "not supported" for external consumption (What is the Capacity Metrics app?, Microsoft Learn, checked June 2026); some columns are flagged as "consumption unsupported." The extraction pattern works in practice but may be restricted without notice — validate column output against your own readings. Schedule the notebook as a background job, append each pull to a lakehouse Delta table or Eventhouse, and you own a history store that grows as long as you run it. The full extraction pattern — including the right DAX to pull the Compute page's 30-second timepoints — is in extracting Fabric metrics with SemPy.

What you own: the notebook code, the schedule, the schema migration when Microsoft updates the semantic model (it does), the lakehouse or Eventhouse, and the dashboard built on top. The compute cost of extraction is negligible — a background notebook pulling a day's metrics is a fraction of a CU-hour. The engineering cost is not.

Path 2 — FUAM (Fabric Unified Admin Monitoring)

FUAM is a Microsoft-published community solution accelerator that automates what the DIY extract does, at a larger scope. Rather than querying only the Capacity Metrics model, FUAM wires the Get Activity Events admin API (tenant-wide audit events, up to 30 days natively — Track user activities in Power BI, Microsoft Learn, checked June 2026 — one UTC day per request, max 200 requests/hour) alongside capacity metrics into a managed lakehouse — giving you a single store with both CU consumption data and admin audit events for attribution correlation (Get Activity Events, Power BI Admin REST API, Microsoft Learn, checked June 2026).

FUAM is designed for tenant-wide deployments: a single service principal with Tenant.Read.All scope pulls events across all workspaces, lands raw JSON in a staging table with zero retention, and an update policy parses and deduplicates into a long-term analytics table designed to hold 730+ days of history. It is the closest thing to a turnkey open-source answer to the retention wall.

The catch is the same as any solution accelerator: you deploy it, you operate it. The service principal needs ongoing credential maintenance. The Jumpstart framework (fpm-activity-events) that underpins FUAM's event extraction needs updates when API schemas or rate limits change. You need data-engineering bandwidth to troubleshoot when the nightly pipeline fails — and it will fail occasionally. "Free" means free-of-license-cost, not free-of-effort.

Path 3 — Purpose-built vault (SpendWeave Pro)

A purpose-built vault runs the extraction, storage, schema migration, deduplication, and alerting pipeline for you — inside your own tenant, using your own capacity, so your data does not leave your Azure boundary. SpendWeave Pro is this option: it deploys into your tenant, extracts the Capacity Metrics model on a continuous schedule, stores multi-year history in your Eventhouse, and surfaces per-item attribution and throttling alerts in a pre-built dashboard. When Microsoft updates the semantic model schema, the update ships to you — you do not debug it.

The trade-off is a subscription cost and less flexibility to customize the schema or extract additional metrics that are not part of the standard coverage. If your team has strong Fabric data-engineering capacity and wants full ownership, DIY or FUAM are reasonable; if you want the history and attribution without operating the pipeline, a purpose-built vault is the honest answer.

The build-vs-buy table

This is the build-vs-buy-table for this article — a scoring of the three alternatives across the five dimensions that actually matter. Ratings reflect a typical enterprise deployment as of June 2026. "Effort" is total-cost-of-ownership including setup, schema maintenance, and pipeline operations — not just initial build time.

One row that surprises most teams: ongoing operations effort. The DIY path scores High not because the initial notebook is hard to write, but because the Capacity Metrics semantic model schema is updated by Microsoft on their schedule, not yours. When the table names or column names change, your extraction breaks silently — producing rows of nulls, or failing the notebook outright. Teams that have run this pattern for 12+ months report at least one schema-change incident per quarter. FUAM is somewhat more resilient because it is maintained by a broader community, but you still absorb the operational impact.

The attribution row is also worth reading carefully. All three paths can achieve item-level attribution (which item consumed which CUs) — that is what the Capacity Metrics model provides. Per-run and per-user attribution requires joining capacity data to the Activity Events admin API, which the DIY path leaves to you, FUAM includes in its architecture, and a purpose-built vault pre-joins. If your FinOps use case is "we need to do quarterly chargeback by team," item-level is probably enough. If your use case is "we need to trace last Thursday's throttle to the specific pipeline run and the user who triggered it," you need the activity-events join — and that is where FUAM or a purpose-built vault pulls ahead of a minimal SemPy extract.

Pausing is a valid escape valve — but it comes with a cost

One option worth understanding before you reach for it: pausing the capacity to end an active throttle. Microsoft explicitly endorses this for F SKU capacities — the throttling guidance lists "Pause and then resume your capacity" as one of the recommended strategies to stop throttling, and the pause-resume documentation calls it a self-service mechanism that ends throttling immediately.

Pausing does work. But it is not a free reset. When you pause, all accumulated smoothed and cumulative carry-forward overage settles to your Azure bill immediately at PAYG rates. On reserved capacity you still pay the reservation commitment regardless, and the settled overage is added as a separate PAYG charge on top. Any background jobs in-flight when the capacity pauses are killed and must be rerun.

The accurate SpendWeave stance: pausing is a valid escape valve Microsoft endorses for F SKUs — but you pay the accumulated overage immediately when you do, so it is not free. Understand that cost before pulling the lever. Alternatives — scaling up temporarily, fixing the underlying query, or rescheduling the workload — avoid that immediate billing event and are usually the better first option. None of the extract paths above require or recommend pausing as routine practice.

What to do next

1. Decide your attribution requirement first. If you need only item-level CU history for trend and forecasting, a SemPy extract is the lowest-friction build. If you need per-run or per-user attribution for incident triage and chargeback, plan for the activity-events join — which is included in FUAM and in a purpose-built vault but not in a minimal notebook extract.

2. Extract before day 15. Whatever path you choose, start it before the 14-day compute window closes on your oldest data. A SemPy notebook that appends yesterday's metrics takes a day to write and produces no value if you start after your oldest useful data has already rolled off.

3. Test schema resilience. If you build a DIY extract, write a test that validates the expected columns exist after each pull — before you append to the long-term table. Silent schema changes that produce nulls for months are far worse than a noisy pipeline failure on day one.

4. Pair alerting with history. Long-term history is retrospective; throttling alerts are prospective. The two are complementary, not alternatives. If you are building a DIY vault, add a Data Activator rule on the Real-Time hub capacity events stream so you catch throttling as it happens — not two weeks later when you query the history.

5. Evaluate FUAM before you build from scratch. If you need the activity-events pipeline alongside the metrics extract, FUAM gives you a working blueprint rather than a blank page. The deployment takes a weekend; the greenfield equivalent can take a month.

The named enemy this article defeats is the metrics-retention wall — the 14-day compute window that makes long-term Fabric capacity history impossible natively. The attribution void is its partner in crime. Both have real solutions, and the build-vs-buy table above is the honest scorecard for picking among them.

Frequently asked questions

What are the alternatives to the Fabric Capacity Metrics app? There are three realistic alternatives for teams that need history beyond the 14-day compute window: a SemPy/DAX extract you build yourself (query the Capacity Metrics semantic model on a schedule and land the data in your own lakehouse), FUAM (the community Fabric Unified Admin Monitoring solution accelerator, which wires the admin APIs and metrics into a managed lakehouse), and a purpose-built vault like SpendWeave Pro. As of June 2026, the metrics app also has a preview Item History page that extends the native compute view to 30 days — but that is still a rolling window and does not solve the long-term or attribution gap.

Does the Fabric Capacity Metrics app keep more than 14 days of data? The Compute page keeps 14 days of compute detail. The Storage page keeps 30 days. As of June 2026 there is also a preview Item History page that extends the compute view to 30 days at item level — but this is still a rolling window. None of these windows can be configured to grow. Any question that spans more than 30 days requires an external extract.

What is FUAM and how does it compare to the Capacity Metrics app? FUAM (Fabric Unified Admin Monitoring) is a community/Microsoft solution accelerator that wires the Fabric admin APIs and the Capacity Metrics semantic model into a lakehouse so you can keep multi-year history. Unlike the metrics app, FUAM is infrastructure you deploy and operate in your own tenant. You get full control and unlimited retention, but you own the pipeline health, schema updates when the semantic model changes, and data-engineering overhead.

Can SemPy extract data from the Capacity Metrics semantic model? Yes — with a caveat. SemPy's evaluate_dax function can query the Capacity Metrics semantic model from a Fabric notebook via XMLA. You can also call the Power BI executeQueries REST API (100k-row cap per call, Build access required). Note: Microsoft explicitly marks the Capacity Metrics semantic model as unsupported for external consumption — treat both paths as best-effort workarounds that may break without notice. The extraction pattern is covered in extracting Fabric metrics with SemPy.

How much does it cost to build your own Fabric metrics history store? The compute is cheap — a scheduled background notebook drawing a fraction of a CU-hour per pull. The real cost is engineering time and ongoing maintenance: schema migrations when the semantic model changes, credential rotation, backfill after pipeline failures, and dashboard build. Teams typically underestimate this by 3–5x. FUAM reduces the greenfield build effort but you still own operations.

Researched with AI assistance, written and fact-checked by Jonathan Flach, verified against Microsoft Learn.