What is a capacity unit (CU) in Microsoft Fabric?

The compute currency of Fabric. Every SKU provides a fixed CU budget (an F64 provides 64 CUs), and every operation — a report query, a dataset refresh, a notebook run, a pipeline — consumes CU-seconds from that shared pool. Your bill is driven by the SKU you provision, so FinOps in Fabric means managing what drains the pool.

When should I upgrade my Fabric SKU?

After optimization, not instead of it. Each SKU step roughly doubles the cost, so buying headroom to cover a refresh pile-up or one runaway notebook is the most expensive possible fix. Upgrade when utilization stays high across the day even after schedules are spread, heavy items are tuned, and dead workloads are retired — that is genuine growth, and the next SKU is the right answer.

Can I see which team is consuming my capacity?

Only indirectly through Microsoft tooling: the Capacity Metrics app shows consumption per item, and items belong to workspaces. Mapping workspaces to teams and holding the history long enough to cover a billing period is your job — which is why chargeback usually needs a long-term, per-item consumption store joined to a workspace inventory.

Fabric FinOps: Capacity Cost Control

The Fabric invoice is one line — the capacity. What actually drives it is thousands of operations a day across every workspace on that capacity: report queries, scheduled refreshes, dataflows, notebooks, pipelines, all drawing from the same compute pool. Fabric FinOps is the discipline of connecting the one number finance sees to the thousands of operations engineering controls.

CU economics in five minutes

Fabric SKUs run F2 → F2048; each provides that many capacity units (an F64 = 64 CUs) and each step up roughly doubles both capacity and cost.
Every operation consumes CU-seconds — interactive ones (report queries) and background ones (refreshes, dataflows, notebooks) share one pool.
Reserved-capacity pricing runs roughly 40% below pay-as-you-go — but only pays off when the SKU is actually the right size.
Power BI Premium P-SKUs have converged on the same F-SKU model, so this math now covers classic Premium estates too.

Smoothing: why the bill never spikes when you expect

Fabric does not charge consumption at the moment it happens. Interactive operations are smoothed over a short window (minutes), background operations over 24 hours — a two-hour refresh at 03:00 becomes a thin layer of consumption spread across the whole day. This protects you from momentary spikes, but it also means cost analysis on "what ran when" is misleading without per-item consumption data: the pain shows up hours after the cause.

Attributing cost to workspaces and teams

Chargeback (or even honest showback) needs three joins Microsoft leaves to you: per-item CU consumption over a full billing period, item → workspace mapping, and workspace → team ownership. The Capacity Metrics app gives you the first for about 14 days; the rest is inventory work. Once joined, the questions that matter become answerable: which workspaces consume the most, what share is background refresh versus interactive use, which team’s footprint is growing.

Scale or optimize? A decision rule

When a capacity runs hot, the expensive reflex is upgrading the SKU. Optimize first when consumption is concentrated — a few items dominating, refreshes piled onto the same hour, zombie datasets refreshing for nobody. Typical wins:

Spread scheduled refreshes away from the shared peak hour.
Move heavy models to incremental refresh instead of full loads.
Retire unused reports and stop their orphaned datasets refreshing.
Right-size or isolate dev/test workloads off the production capacity.

Upgrade when utilization stays high after the concentration is gone — broad, sustained load across many healthy items is real growth, and the next SKU is cheaper than the organizational cost of a throttled capacity.

The continuous approach

PGR Sonar keeps Fabric capacity metrics as long-term history — per item, per operation, interactive vs background — joined to the workspace inventory. That turns FinOps from a fortnightly screenshot exercise into standing answers: heaviest items ranked over months, workspace-level consumption for chargeback, and Capacity Diagnostics recommendations that point at the specific datasets, dataflows or notebooks worth optimizing before you pay for the next SKU.

Fabric FinOps: Understanding and Controlling Capacity Costs