Monitoring with the capacity metrics app

The instrument: the Fabric Capacity Metrics app

Microsoft ships the Microsoft Fabric Capacity Metrics app — a Power BI app (installed by a capacity admin, pointed at each capacity) that surfaces the telemetry Fabric collects. It is the authoritative, near-real-time view of capacity health, far better than guessing from user complaints.

What to read, in order

1. CU utilisation over time — the base view: are you near, at, or over the SKU's CU budget, and when. Sustained lines above 100% mean throttling is coming.
2. Throttling / overload indicators — explicit signals for interactive delay, interactive rejection, and background rejection windows (the throttling concept). This tells you whether users actually felt anything.
3. Smoothing / carry-forward — how much borrowed CU is being paid down, explaining lag between a spike and a slowdown.
4. Top operations / items — the ranked list of which semantic models, reports, refreshes or Fabric jobs consumed the most CU. This is the drill-through that finds the culprit.

Finding the noisy neighbour

Because all workloads share one capacity's CU, a single heavy item — an inefficient refresh, a runaway DAX query, a large data-engineering job — can degrade everything else. The metrics app's top-operations view, filtered to the overload window, names it. The fix is usually to tune that item, reschedule it, or move it to its own capacity — not to blindly upsize.

Guardrail practices

• Baseline and alert — know normal CU, and watch for sustained overload rather than reacting to complaints.
• Stagger heavy refreshes so they don't collide and spike the budget together.
• Separate dev/test onto their own (pausable) capacity so experimentation can't throttle production.
• Right-size from evidence — resize up only when the metrics show chronic overload, down when they show idle headroom.

Failure modes

• Flying blind — no metrics app installed, so capacity problems are only ever diagnosed after users complain.
• Upsizing reflexively — throwing a bigger SKU at a single bad model instead of fixing it, inflating cost permanently.
• Ignoring smoothing — blaming the current moment for a slowdown whose cause was a spike hours earlier.
• No dev/prod separation — a developer's experiment throttles the audience's reports.

What to watch (proofs)

• The metrics app itself: installed and current per capacity — its CU, throttling and top-operations pages are the primary proof surface.
• Capacity inventory to monitor: Get-PowerBICapacity / admin/capacities enumerates every capacity that needs a metrics view.
• Top consumers vs owners: the app's worst operations tied back (via Get-PowerBIWorkspace -Scope Organization) to the owning workspace/team — attribution for the guardrail conversation.
• Overload-to-refresh correlation: Get-PowerBIDataset refresh failures during the app's overload windows — user-visible impact.
• Activity context: Get-PowerBIActivityEvent around spikes — what users/jobs were doing when the capacity peaked.