How long does the Fabric Capacity Metrics app keep data?

About 14 days. The app is designed for near-real-time monitoring and short-term diagnosis, not for history. Anything older — last month’s throttling incident, seasonal trends, year-over-year growth — is gone unless you exported it while it was still visible.

Can I see which report or notebook consumed my capacity?

Yes — capacity metrics are recorded per item and operation, with compute-unit (CU) consumption and whether the load was interactive or background. The metrics app shows this at timepoint level; a long-term store lets you rank the heaviest items over months instead of days.

What typically causes Fabric capacity throttling?

Sustained CU consumption above the SKU limit. The usual suspects are scheduled refreshes piled onto the same hour, runaway dataflows or notebooks, and a handful of heavy semantic models. Finding them requires per-item consumption history around the throttling window.

Fabric Capacity Metrics History Beyond 14 Days

If you run Power BI Premium or Microsoft Fabric capacities, the Microsoft Fabric Capacity Metrics app is where you look when things slow down. It is genuinely good at what it does — near-real-time, timepoint-level compute-unit (CU) detail per item and operation. It has one structural limitation: it only retains about 14 days of data.

Why 14 days is not enough

Incident forensics: "why were we throttled during month-end close?" is usually asked well after the window has rolled off.
Capacity planning: SKU sizing decisions need months of trend, not a fortnight.
Chargeback: attributing capacity cost to teams requires per-item consumption over full billing periods.
Optimization proof: you cannot show that rescheduling refreshes helped if the "before" data no longer exists.

The DIY route: exporting the metrics dataset

The metrics app is backed by a semantic model, and admins can query it — connect with the XMLA endpoint or Analyze in Excel, run DAX against tables like the timepoint detail, and schedule an export into your own database before the window rolls off.

It works, but know what you are signing up for: the app’s internal model is not a documented public contract and changes between app versions, the export needs its own scheduler and credentials, and a missed fortnight is unrecoverable.

What a long-term capacity store should hold

Timepoint-level CU consumption per item (report, semantic model, dataflow, notebook, lakehouse) and operation, flagged interactive vs background.
Utilization as a percentage of the SKU limit, so peaks and throttling windows are visible months later.
Enough joinability to answer "which workspace / which team" — inventory context, not just raw numbers.

The continuous approach

PGR Sonar reads Fabric capacity metrics on schedule and stores them as long-term, queryable history tied to your tenant inventory — so throttling investigations, trend planning and heaviest-item rankings work over months, not 14 days. Capacity Diagnostics goes one step further and tells you what to do: which datasets, dataflows or notebooks to reschedule or optimize to stop overloading the capacity.

Fabric Capacity Metrics: Keeping History Beyond 14 Days