What Is a Capacity Unit (CU)? How Microsoft Fabric Billing Works

An F64 Microsoft Fabric capacity delivers 64 Capacity Units (CUs) per second and costs $8,409.60/month at pay-as-you-go rates — that is 64 × $0.18 × 730 hours (all figures as of June 2026). Every single workload on the platform — Power BI report renders, Spark notebooks, Warehouse SQL, pipeline runs, Dataflow Gen2 refreshes — draws from the same CU pool. The CU is the atom of Fabric billing, and understanding how it is measured, smoothed, and billed is the prerequisite for any Fabric cost work.

This article is the foundational CU explainer. For the full F-SKU price table and tier-selection decision flow, see the Microsoft Fabric pricing and capacity planning guide.

What exactly is a Capacity Unit

A Capacity Unit is a normalized measure of compute that abstracts over the underlying hardware. Instead of paying separately for Spark vCores, SQL compute, Power BI Premium nodes, and Data Factory DIUs, Fabric converts all of that into a single currency — CUs per second — billed at $0.18 per CU-hour (Azure pricing page, checked June 2026).

Your F-SKU number is your per-second CU baseline:

Formula: CUs × $0.18 × 730 hours. Storage is decoupled and billed separately — OneLake is roughly $0.023/GB-month (OneLake capacity consumption, Microsoft Learn, checked June 2026).

The Capacity Metrics app surfaces usage in CU-seconds, not CU-hours, because individual operations often complete in under a minute. The billing arithmetic is straightforward: divide CU-seconds by 3,600 to get CU-hours, then multiply by $0.18.

Interactive vs background operations

Fabric divides every operation into one of two categories, and the category determines how fast overage accumulates into throttling (Fabric operations, Microsoft Learn, checked June 2026).

Interactive operations are on-demand requests triggered by user actions:

• Power BI report renders and visual refreshes
• DAX queries from report visuals or XMLA endpoints

"Most operations in the Warehouse category are reported as background to take advantage of 24-hour smoothing of activity to allow for the most flexible usage patterns." — Data Warehouse Billing and Utilization Reporting, Microsoft Learn, checked June 2026.

The exception is Warehouse modeling operations — creating measures, visualizing results, or creating/updating Power BI semantic models or reports — which are classified as interactive and follow the Interactive Rejection policy (Smoothing and Throttling, Microsoft Learn, checked June 2026).

Background operations are longer-running jobs, whether scheduled or manually triggered:

• Semantic model scheduled refreshes
• Spark notebook runs — including runs triggered manually from the UI
• Data Factory pipeline activities (copy, dataflow, orchestration) — including on-demand runs
• Dataflow Gen2 refreshes
• Copilot requests (classified as background in the billing engine)

The distinction is not cosmetic. It determines the smoothing window — the period over which Fabric spreads a job's CU cost across future timepoints. Interactive operations smooth over a minimum of 5 minutes and up to 64 minutes depending on total CU consumption. Background operations smooth over a 24-hour window (Understand your Fabric capacity throttling, Microsoft Learn, checked June 2026).

How 30-second timepoints and smoothing work

The Capacity Metrics app measures utilization in 30-second intervals called timepoints. A 24-hour background smoothing window spans exactly 2,880 timepoints (24 × 60 × 2). When a background job begins, its total CU cost is divided evenly across those 2,880 timepoints (Understand the metrics app timepoint page, Microsoft Learn, checked June 2026):

"Every background operation that completed within the last 24 hours (defined as a window of 2,880 intervals, each lasting 30 seconds) contributes a small portion of its total usage to the CU value."

The practical consequence: a large background job that consumed 6× an F2's hourly allowance in one shot gets diluted across a full day's worth of timepoints and will not cause throttling. An interactive query that spikes at the same magnitude surfaces its full CU cost within 5–64 minutes and, because there is no 24-hour dilution buffer, can exhaust the 10-minute overage protection window and trigger throttling far faster than a background job of the same size.

When the smoothed combined CU load across interactive and background operations exceeds the capacity's 30-second timepoint allowance, the platform enters progressive throttling — not a crash, but a staged escalation (Understand your Fabric capacity throttling, Microsoft Learn, checked June 2026):

A background-rejection reading of 250% in the Metrics app means you consumed 2.5× your daily CU allowance — it is a measure of how much you have overdrawn the capacity's 24-hour CU budget, not a live instantaneous utilization percentage.

One trap to avoid: pausing the capacity to clear the throttling backlog. Pausing bills all accumulated smoothed background debt immediately at PAYG rates — the cost you were trying to defer becomes due at once. Scale up the SKU temporarily or wait for carryforward to burn down instead. Never pause to clear throttling — pausing triggers a PAYG settlement of all smoothed overage immediately. If throttled, scale down the SKU or fix the offending query instead. See the pause/resume trap.

From CU-seconds to a dollar figure: a worked example at F64

This is the worked calculation that turns raw Capacity Metrics numbers into a dollar figure. The scenario: an F64 capacity that hosts a mix of interactive Power BI traffic and an overnight Spark pipeline.

Step 1 — read CU-seconds from the Metrics app

The Metrics app timepoint detail shows the following during a one-hour window (6 AM–7 AM):

The background number is the amortized share — the pipeline's 24-hour smoothing window started at 02:00 when the job began (not at 04:00 when it finished), so by 6 AM the smoothed cost has already been spreading for four hours across 2,880 timepoints. The figure shown is that running share summed back over the 120 timepoints (60 minutes × 2) in this observation window.

Step 2 — convert CU-seconds to CU-hours

36,000 CU-seconds ÷ 3,600 = 10 CU-hours

Step 3 — multiply by $0.18

10 CU-hours × $0.18 = $1.80 for this one-hour window

Extrapolated at this average rate across 730 hours/month: ~$1,314/month — roughly 15.6% of the F64's $8,409.60/month capacity ceiling. That means 84% of the paid capacity is idle or headroom during this window.

Interactive vs background cost split

Isolating the two operation types in the same window:

The pipeline accounts for 60% of spend in this window despite completing hours earlier — because its 24-hour amortization distributes cost far beyond the job's actual runtime. This is the mechanic behind what we call the attribution void: the Capacity Metrics app shows the amortized CU contribution at each timepoint, but the OperationID in the metrics data does not link back to the original pipeline run that generated it. You can see how much background CU was consumed; you cannot automatically join it to a specific pipeline execution without building a correlation layer on top.

What this means for your bill

The F64 ceiling is 64 CUs/second = 1,920 CU-seconds per 30-second timepoint (64 × 30), or 3,840 CU-seconds per minute. The 36,000 CU-seconds in the example above average 600 CU-seconds per minute — 15.6% of the F64's 3,840 CU-second per-minute ceiling — comfortable, with room to grow. The throttling wall arrives when smoothed usage pushes toward 100% of the capacity's future-capacity window. Track this in the Metrics app; the main Compute page holds 14 days of compute detail — the primary sizing window. The Item History page (preview, in the same app) extends item-level compute analysis to 30 days, matching the storage and workspace monitoring retention. Pull a representative fortnight from the Compute page before committing to a reservation; use Item History to spot longer trends.

For a deeper walkthrough of how this math rolls up to a monthly estimate, see the monthly Fabric bill estimator walkthrough.

The named enemy: the attribution void

The worked example above surfaces a structural gap in the Fabric billing model. Attribution is item-level only — the Capacity Metrics app can tell you which item kind (Spark notebook, Power BI dataset, pipeline) consumed CUs, but the OperationID for a background job is not linked to the pipeline run or schedule trigger that invoked it. There is no default per-workspace CU isolation — by default, one workspace's runaway Spark job depletes the same pool that serves every other workspace on the capacity. Workspace-level surge protection (Preview) lets admins set CU percentage limits per workspace, but it requires explicit configuration and is not on by default. Without it, the throttling blast radius is the whole capacity. Workspace-level surge protection shipped in preview (January 2026), but it throttles/limits a workspace's background usage against an admin-set threshold rather than giving each workspace a guaranteed CU reservation — so the tenant-wide blast radius still applies unless explicitly configured.

SpendWeave's audit surfaces item-level consumption from the Capacity Metrics semantic model, grouped by workspace and item, so you can see which items are driving cost even when the pipeline-run linkage is missing.

What to do with this

1. Find your CU-seconds in the Metrics app. Open the timepoint detail view, filter to your heaviest day in the last 14 days, and note total CU-seconds for interactive and background separately.
2. Convert to dollars. Divide by 3,600, multiply by $0.18. If the number is close to your capacity's hourly ceiling, you are close to throttling.
3. Check your background amortization. If background CU-seconds are high in quiet hours (overnight, weekends), your pipeline is distributing cost across the full day. Size from the smoothed 24-hour peak, not the instantaneous spike.
4. Identify the attribution void. Match high-CU items to workspace and item name. Build a correlation layer in Excel or Power BI if you need pipeline-run-level attribution — the Metrics app alone cannot close that gap natively.
5. Cross the F64 line only if the viewer math supports it. The CU mechanic is the same above and below F64; the licensing threshold is the only architectural break. See the full F-SKU pricing breakdown for the crossover arithmetic.

For the full explanation of how smoothed debt can accumulate and trigger the throttling blast radius, see how to monitor Fabric capacity health and throttling signals.

If you want this kind of plain-math teardown in your inbox each month, subscribe to the SpendWeave Fabric cost teardowns — real capacity bills, dissected.

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