How long does the Fabric Capacity Metrics app keep data?

The Capacity Metrics app keeps 30-second-granularity compute detail for 14 days on its Compute page, daily-granularity compute trends for 30 days on its Item History page (Preview), and storage data for 30 days on its Storage page, per Microsoft Learn (checked June 2026). All are rolling windows. There is no native setting to extend any of them. Sub-day forensic detail beyond 14 days, or any history beyond 30 days, requires an external store you populate before the window closes.

Can I extend the Capacity Metrics app retention period?

No. There is no admin setting, tenant switch, or SKU upgrade that extends the 14-day compute or 30-day storage windows in the Capacity Metrics app. A common workaround is to extract data before it ages out — schedule a SemPy notebook or Power BI executeQueries call against the Capacity Metrics semantic model, appending each pull to a lakehouse or Eventhouse you control. Note: Microsoft documents external usage of the Capacity Metrics semantic model as unsupported, so treat this as a best-effort workaround that may be restricted without notice. That external store has no platform-imposed retention limit — you choose how long to keep it.

What is the Fabric Workspace Monitoring retention period?

The Workspace Monitoring Eventhouse — Microsoft's per-workspace observability feature — retains monitoring data for 30 days, per Microsoft Learn (checked June 2026). That is the same limit as the Capacity Metrics app's storage page and the Monitoring Hub's Spark history. All three hit the same 30-day ceiling. Longer history requires either persisting to your own Eventhouse with a custom retention policy, or an external vault.

Does pausing a Fabric capacity reset the throttling history in the Metrics app?

Pausing technically terminates any active throttle because the capacity goes offline, but it is a costly trap — not a fix. All smoothed and cumulative overage that had been deferred settles immediately to the bill at PAYG rates. On a reserved capacity you also keep paying the reservation. The Metrics app will show no throttling after a pause because the capacity was not running, but your bill will reflect the overage anyway. The right fix for persistent throttling is to scale up, fix the offending query, or schedule heavy workloads to off-peak hours — not to pause.

Fabric Capacity Metrics Retention: 14-Day Compute Limit, 30-Day Storage — and How to Keep History

Q: How do I export Capacity Metrics data before it is deleted?

A common practitioner pattern is a scheduled SemPy notebook using evaluate_dax() against the Capacity Metrics semantic model (dataset ID visible in the app URL), appending results to a lakehouse Delta table you own. Alternatively, call the Power BI executeQueries REST API directly — one query per request, 100,000-row cap. Caveat: Microsoft documents the Capacity Metrics semantic model as only supported for use by the app's own reports — external querying is unsupported and may be restricted without notice. Run the extraction at least once every 13 days to guarantee no gap.

The Microsoft Fabric Capacity Metrics app keeps 14 days of compute detail and 30 days of storage data — and there is no native setting that changes either number. On day 15, that compute history is gone. No archive. No rollback. Any capacity question that spans more than two weeks — monthly trending, quarterly chargeback, post-incident forensics from three Tuesdays ago — runs straight into what the complete guide to Microsoft Fabric capacity monitoring calls the metrics-retention wall. This article explains exactly what each surface retains, why the wall exists, and the precise extraction pattern that builds multi-year history before the window closes.

The retention matrix

Seven native surfaces carry capacity monitoring data in Fabric. Each has its own ceiling and its own blindspot. The table below is the retention-matrix-and-vault-wedge — the precise map of what the platform keeps, what it drops, and what an external vault must cover to fill the gap.

Surface	What it holds	Compute detail retention	Storage detail retention	Extendable natively?
Capacity Metrics app — Compute page	CU utilization, throttling stages, per-item breakdown at 30-second timepoints	14 days (rolling)	—	No
Capacity Metrics app — Item History page (Preview)	Per-item daily CU, operation status, throttling seconds, scheduling frequency — 30-day compute trends at daily granularity (not 30-second timepoints)	30 days (rolling, daily granularity)	—	No
Capacity Metrics app — Storage page	Current and billable storage by workspace, soft-deleted data trends	—	30 days (rolling)	No
Workspace Monitoring Eventhouse	Item-level query logs, Spark events, pipeline runs, per-workspace telemetry	30 days (rolling)	30 days (rolling)	Only by routing to a custom Eventhouse with its own retention policy
Monitoring Hub (Spark History)	Spark job run list, stages, task detail	30 days	—	No
Real-Time hub capacity events	30-second CU summary + state-change events per capacity	Only what you persist to an Eventhouse	Only what you persist	Yes — you own the Eventhouse
Activity Events admin API	Tenant-wide user and system audit events	~28–30 days (one day per API request)	—	Only by scheduled extraction to an external store
External vault (custom)	Whatever you extract from the above	Unlimited — you set the policy	Unlimited	Fully extendable

Sources: What is the Microsoft Fabric Capacity Metrics app?, Microsoft Learn, checked June 2026; Item History page, Microsoft Learn, checked June 2026; Workspace Monitoring Overview, Microsoft Learn, checked June 2026; Spark monitoring best practices, Microsoft Learn, checked June 2026.

The pattern is consistent across every native surface: each one is a rolling window, not a durable record. The Compute page is the most granular — 30-second timepoints over 14 days. The Item History page (Preview) extends compute visibility to 30 days but trades granularity: it shows daily CU totals and operation counts, not 30-second timepoints. Storage and workspace monitoring also sit at 30 days. None of them extend.

The vault wedge — the gap between what the platform keeps and what FinOps actually needs — opens immediately on day 15 of compute history and grows by one day every day you do not extract. A team that waits until month-end to pull data for a chargeback report will find roughly half of that month's compute detail already gone.

Why the wall exists and why it will not move

The Capacity Metrics app is a Power BI app backed by a system-managed semantic model Microsoft operates for you. You do not own the semantic model's storage, its refresh schedule, or its retention policy. The 14-day compute window and 30-day storage window are hard-coded in that managed model — they are not capacity-admin settings you can toggle (Capacity Metrics app compute page, Microsoft Learn, checked June 2026). There is no Premium-tier override, no F2048 exception, no tenant admin switch. The wall applies equally to a $262.80/month F2 and a $134,553.60/month F1024 (both as of June 2026, PAYG).

This is different from the Workspace Monitoring Eventhouse, where you can route telemetry to a custom Eventhouse and set its own retention policy (Workspace Monitoring Overview, Microsoft Learn, checked June 2026). For the Capacity Metrics app's Compute page there is no equivalent. The only way to hold 30-second-granularity compute data longer than 14 days is to pull it out before day 15 and store it somewhere you control.

What the 14-day wall actually costs you

The practical failure modes are concrete:

Monthly chargeback loses sub-day granularity. The Item History page (Preview) does cover a full 30-day billing cycle at daily item-level granularity (Item History page, Microsoft Learn, checked June 2026), so daily CU totals per item are available natively for the whole month. What is missing is 30-second resolution: you cannot reconstruct exactly which minute of which day a throttle spike hit, or separate two jobs that ran back-to-back within the same day. For forensic-grade chargeback — proving to a department head that their pipeline caused a throttle at 14:32 on the 4th — you still need an external store with the 30-second compute extract.

Post-incident forensics go cold at 14 days. A capacity throttles on day 1 of the month. By day 15, the 30-second compute evidence from the Compute page — which items were running, what the per-second CU peaks looked like, when the interactive-rejection window opened — has been purged. The Item History page will still show that day's daily CU total and the throttling seconds applied, but the sub-day forensic trace is gone. You cannot reconstruct the sequence of events from daily aggregates alone.

Trending and forecasting beyond 14 days require the Item History page or an external store. "Is our capacity growing month-over-month at the 30-second level?" requires the external extract. At daily granularity, the Item History page's 30-day window makes month-over-month item trends visible natively — but for multi-month or quarterly forecasting ("Will we need to upgrade from F32 ($4,204.80/month PAYG) to F64 ($8,409.60/month PAYG) by Q3?"), you still need an external store with history beyond 30 days.

Quarterly and annual planning relies on guesswork. Budget cycles, contract renewals, reserved-capacity decisions (which carry a 40.51% discount over PAYG but require committing to a year) — all of them depend on utilization trends spanning more than 30 days. No native surface covers that window.

The extraction pattern: how to vault your metrics before they expire

The fix is not complicated — it is just mechanical. Run the extraction on a schedule that guarantees no gap. The critical constraint: the Capacity Metrics semantic model holds 14 days of compute detail. Pull at least once every 13 days to guarantee overlap. Daily pulls are better and cost very little.

Unofficial pattern — use with caution. Microsoft's documentation explicitly states that the Capacity Metrics semantic model "is only supported for use by the reports provided in the application" and that "any consumption from, usage of, or modification of the semantic model isn't supported" (What is the Microsoft Fabric Capacity Metrics app?, Microsoft Learn, checked June 2026). The extraction pattern below works in practice and is used by advanced practitioners (including DAX Studio direct-query workflows), but Microsoft may restrict or break external access without notice. Treat it as a best-effort workaround, not a supported integration. If reliability matters, plan for the possibility of it stopping working and have a fallback (such as SpendWeave Pro, which handles extraction on your behalf).

Step 1 — locate the semantic model ID. Open the Capacity Metrics app in your browser. The URL contains the dataset (semantic model) ID: https://app.powerbi.com/groups/<workspaceId>/reports/<reportId>. The workspace ID is the capacity-metrics workspace. Query the Power BI REST API to enumerate datasets in that workspace and identify the Fabric Capacity Metrics model. In the huidemo tenant it is 9375e6c9-af35-4a7c-855d-82609b942973 — yours will differ.

Step 2 — query via SemPy or the executeQueries REST API. From a Fabric notebook with the sempy library:

import sempy.fabric as fabric

df = fabric.evaluate_dax(
    dataset="Fabric Capacity Metrics",
    dax_string="""
    EVALUATE
    SELECTCOLUMNS(
        'TimePoint',
        "CapacityId",      [CapacityId],
        "TimePoint",       [TimePoint],
        "ItemName",        [ItemName],
        "ItemKind",        [ItemKind],
        "CUSeconds",       [CUSeconds],
        "ThrottlingState", [ThrottlingState]
    )
    """
)

Alternatively, call the Power BI executeQueries REST API directly — one query per request, 100,000-row cap per call (paginate by time range — one day per call — if your tenant exceeds that limit; the XMLA endpoint via a tool like DAX Studio has no fixed row cap):

.venv/bin/fab api -A powerbi -X post \
  "groups/<workspaceId>/datasets/<datasetId>/executeQueries" \
  -i '{"queries":[{"query":"EVALUATE SELECTCOLUMNS(TimePoint, ...)"}],"serializerSettings":{"includeNulls":true}}'

Step 3 — append to a Delta table you own. Land each pull as an append to a lakehouse Delta table. Do not overwrite — append, because each day's pull carries that day's complete 14-day window. Deduplicate on the TimePoint + CapacityId + ItemId composite key. Over time, this table becomes your indefinitely long compute record.

Step 4 — schedule the notebook. Use a Fabric pipeline or a scheduled notebook trigger. Run daily during low-capacity hours. At the cost of a few CUs per run, you buy years of history the native tools will never give you.

The Activity Events admin API follows the same pattern — one day per request, ~28–30 days available, so again daily is the right cadence. Join the activity events to your capacity extract on operation time and item to move from item-level attribution toward per-run attribution — the closest the platform allows you to get to the attribution void problem.

What you cannot extract (the honest limits)

Extraction does not give you everything:

Sub-item granularity is not available. The semantic model exposes data at item-level (pipeline, notebook, semantic model). It does not expose individual pipeline run IDs or user-level CU consumption. That attribution limit is a platform constraint, not a retention one.
The 100k-row cap matters for large tenants. If you have many items and time points, a single executeQueries call may hit the row cap mid-pull. Paginate by time range — pull one day at a time — or use the XMLA endpoint via a tool like DAX Studio, which has no fixed row cap.
The semantic model only exists while the app is installed. If a capacity admin uninstalls the Capacity Metrics app, the backing semantic model disappears. Your extraction pipeline will fail. Monitor for this.
Dimensions (workspace and item names) refresh at midnight local time. A new workspace or item will not appear in the metrics model until the next midnight refresh, per Microsoft Learn (checked June 2026). Your extract will pick it up on its first post-midnight pull.

For a broader view of what the native monitoring stack covers and where each tool stops, the Capacity Metrics app alternatives article maps every surface against the monitoring needs FinOps teams actually have.