Fabric capacity cost is not set by the rate card. It is set by CU-seconds consumed, smoothed across 30-second timepoints, and by how fast you clear carryforward before throttling starts. EPC Group runs capacity as an operating discipline: named roles, a monitoring cadence with thresholds, and a Capacity Debt Ledger. EPC Group is a Houston-based Microsoft consulting firm operating since 1997, with six Microsoft Solutions Partner designations.
Quick facts
| Question | Answer |
|---|---|
| Unit of consumption | Capacity Unit second (CU-second); 1 CU-hour = 3,600 CU-seconds |
| Evaluation window | 30 seconds (a “timepoint”) |
| CU-hours per day, F64 | 1,536 (F256 = 6,144; F512 = 12,288) |
| Smoothing | Interactive 5–64 minutes; background 24 hours |
| First throttling stage | 20-second delay on new interactive operations |
| Primary instrument | Fabric Capacity Metrics app (Compute 14 days; Storage 30 days) |
| Fastest way to stop throttling | Pause and resume, or scale up |
| Spark / Warehouse on capacity | 1 CU = 2 Spark vCores or 0.5 Warehouse vCores |
| Chargeback source | Fabric Chargeback app (refreshed daily) |
What a CU-second actually is
For finance. A Fabric capacity is a metered pipe, not a server. The SKU number is the pipe’s width in Capacity Units: an F64 delivers 64 CUs every second, 1,536 CU-hours a day. Every query, refresh, notebook run and pipeline consumes some of that flow, measured in CU-seconds. You are billed for the pipe, not per query, and the question is whether the work fits through it. When it does not, Fabric does not send a larger bill by default — it slows people down. That is why Fabric cost management is really reliability management with a price tag.
For engineers. Multiply the SKU’s CU count by 30 for the CU-seconds available in one 30-second timepoint: an F64 has 1,920. Two mechanisms sit between raw consumption and that ceiling. Bursting lets an operation temporarily use more compute than the SKU provides, so a big job finishes fast. Smoothing then spreads that operation’s CU cost across future timepoints — five to 64 minutes for interactive, 24 hours for background. A one-CU-hour background job on an F2 contributes 3,600 CU-seconds ÷ 2,880 timepoints = 1.25 CU-seconds per timepoint, about 2.1% of each, even though it consumed six times the compute available in the next ten minutes.
The consequence: peak utilization is not the number that matters — smoothed future consumption is. A capacity showing 300% instantaneous spikes may never throttle, while one showing a flat 95% background line is a single bad pipeline away from a 24-hour outage. If you are still on P SKUs, the P-to-F migration runbook comes first, and the F SKU cost model derives the reserved break-even.
The Four-Desk Capacity Operating Model
Most Fabric cost overruns are ownership failures: nobody is accountable for the capacity as an object, so nobody watches it. EPC Group’s Four-Desk Capacity Operating Model assigns four standing responsibilities. One person can hold two desks; the desks still need naming.
| Desk | Accountable for | Fabric permission | Cadence |
|---|---|---|---|
| Capacity Owner | SKU decision, reservation, budget, go/no-go on scaling up | Azure subscription owner / reservation purchaser | Monthly |
| Capacity Steward | Utilization, throttling, surge thresholds, pause schedules, incident response | Fabric capacity administrator | Daily |
| Workload Owner | The CU cost of their workspace — refresh schedules, model design, pipeline efficiency | Workspace admin (+ capacity contributor) | Weekly |
| FinOps Analyst | Allocation, showback, forecast variance, maintaining the Capacity Debt Ledger | Read access to Chargeback and Cost Management | Monthly |
Two permission details matter. A capacity contributor can assign workspaces but cannot change capacity settings or delete the capacity — the correct grant for Workload Owners. Only a capacity administrator can enable surge protection, capacity overage or autoscale billing for Spark. Do not hand capacity admin out for convenience; all three settings have direct cost consequences.
The Capacity Debt Ledger
Capacity debt is the accumulated gap between what a workload was sized for and what it actually costs. It is not a metaphor: Fabric has a literal debt mechanic in carryforward CUs, which accrue when smoothed consumption exceeds a timepoint’s allowance and must be paid off through burndown before throttling stops. The Metrics app Health page reports a Cumulative debt sparkline per capacity. The Ledger extends that from the platform’s 24-hour horizon to your budget’s twelve-month one. Keep one row per workload — usually per workspace — and refresh it monthly from the Chargeback app and the Metrics app matrix.
| Column | Source | Example |
|---|---|---|
| Workload | Workspace or item name | WS-Finance-Reporting |
| Owner | Named Workload Owner | J. Alvarez |
| Sized CU-hours/month | Budgeted at onboarding | 180 |
| Actual CU-hours/month | Chargeback app, Utilization (CU) by date | 274 |
| Debt (CU-hours) | Actual − Sized | +94 |
| Debt ($) | Debt × $0.18 (or reserved equivalent) | $16.92 |
| Debt trend | 3-month direction | ↑ rising |
| Overloaded minutes | Metrics app, matrix by item and operation | 42 |
| Performance delta | Metrics app, % change vs 7 days ago | −18% |
| Root cause | Model design, refresh frequency, concurrency, data growth, new feature | Hourly refresh on a daily source |
| Remediation / due / status | Action, date, Open / In progress / Written off | 2× daily refresh, 2026-09-15, Open |
Four rules make it work.
Rule 1 — every workload gets a size at onboarding. A workspace admitted to a shared capacity without a CU-hour budget cannot accrue debt, because there is no baseline. This is the highest-leverage governance change available.
Rule 2 — debt is denominated in CU-hours first, dollars second. CU-hours are stable across regions and billing models; dollars move with your reservation.
Rule 3 — write-offs are explicit. Sometimes a workload is legitimately bigger than it was sized for. Re-baseline it, record the write-off, raise the forecast. Never let unexplained debt roll forward silently — that is how an F64 becomes an F256 with nobody able to say why.
Rule 4 — the ledger drives the SKU conversation, not the reverse. When total ledger debt exceeds roughly 15% of capacity for three consecutive months and remediation has failed, that is the evidence for a scale-up. Before then, scaling up buys your way out of a design problem. Our data governance practice treats it as a governance artifact.
Monitoring cadence
| Frequency | Metric | Where | Action threshold |
|---|---|---|---|
| Daily | Health status per capacity | Metrics app Health page | Anything other than Healthy or Suspended → Steward investigates same day |
| Daily | Interactive delay % | Compute → Throttling | Any 30-second window >100% → open an incident |
| Daily | Blocked workspaces | Health page | >0 → confirm the block was intended |
| Weekly | 24-hour background % | Compute → Throttling → Background rejection | Sustained >70% → review refresh schedules |
| Weekly | Peak and average utilization | Compute page cards | Average >80% for five consecutive days → begin scale-up analysis |
| Weekly | Overloaded minutes and performance delta by item | Compute → matrix by item and operation | >30 overloaded minutes, or delta worse than −25% week on week → assign to the Workload Owner |
| Monthly | CU-hours by workspace, item, domain | Chargeback app | Variance >20% against ledger baseline → record as debt |
| Monthly | Billed overage CU-hours | Compute → Overages (Billed) | Recurring overage → compare 3× cost against a scale-up |
| Monthly | Reservation coverage, storage growth | Cost Management / Storage page | Uncovered always-on CU → extend the reservation |
| Quarterly | Total ledger debt vs capacity | Capacity Debt Ledger | >15% for three months → SKU decision |
Automate the daily rows. Fabric emits Microsoft.Fabric.Capacity.Summary events every 30 seconds and Microsoft.Fabric.Capacity.State on state change through the Real-Time hub. Build an Activator rule on backgroundRejectionThresholdPercentage, interactiveDelayThresholdPercentage or interactiveRejectionThresholdPercentage that emails the Steward or triggers a user-defined function. Native email alerts at 100% of provisioned CU are also available.
Throttling: the ladder and the recovery maths
Throttling is progressive by design, so refreshes survive longer than dashboards.
| Future capacity consumed | Stage | User impact |
|---|---|---|
| ≤ 10 minutes | Overage protection | None. Jobs may consume 10 minutes of future capacity freely |
| 10–60 minutes | Interactive delay | New interactive operations delayed 20 seconds at submission |
| 60 minutes – 24 hours | Interactive rejection | Interactive operations rejected; background operations still start and run |
| > 24 hours | Background rejection | All requests rejected, interactive and background |
Recovery is calculable: minimum time to recover = ((% of the rejection type − 100) ÷ 100) × window duration. At 250%, that is 15 minutes for interactive delay, 90 minutes for interactive rejection, 36 hours for background rejection. Those are minimums — background jobs keep accumulating future consumption, so real incidents run longer.
Three behaviours change per workload. Almost all Warehouse operations are reported as background to take advantage of 24-hour smoothing, so warehouse users hit rejection rather than delay. Real-Time Intelligence skips the 20-second delay stage and throttles only at the 60-minute rejection threshold. Eventstreams are not throttled at all; the CU allocated to keeping streams open is reduced until the capacity recovers. In-flight operations are never throttled — only new submissions.
Users see status code CapacityLimitExceeded with “Your organization’s Fabric compute capacity has exceeded its limits. Try again later”, or “Cannot load model due to reaching capacity limits.” Put both strings in the service-desk knowledge base so tickets route to the Steward, not the report author.
The throttling-incident response runbook
- Confirm it is throttling, not design. Slow reports are more often a bad semantic model than an overloaded capacity. Open the Compute page, filter to the incident time, and check whether CU% exceeded 100%. If not, hand it to the Workload Owner as a performance problem.
- Identify the stage. Check the Interactive delay, Interactive rejection and Background rejection tabs. Whichever is above 100% tells you what users experience and which recovery window applies.
- Calculate recovery time and publish it. An honest “reports will be rejected for roughly 90 more minutes” beats an hour of silence.
- Decide whether to intervene. Capacities self-heal. If recovery is under 30 minutes and no executive-visible workload is affected, wait.
- If you intervene, choose one lever. Scale up — more idle capacity per timepoint burns down carryforward faster. Pause and resume — pausing bills accumulated smoothed usage immediately and the capacity resumes with zero future consumption, clearing throttling instantly. Capacity overage — pays off the current window at 3×. The trap: enabling overage during heavy throttling charges all cumulative carryforward at the moment you switch it on.
- Find the cause. Drill into the timepoint summary and detail pages to rank operation types and items by CU-seconds in the window that tipped over.
- Apply a control, not just a fix. If one workspace caused it, set a workspace-level surge limit. If background jobs caused it, set a capacity-level background rejection threshold below 100%.
- Post an entry in the Capacity Debt Ledger. Every throttling incident is debt made visible. Record workload, root cause, remediation and owner before closing.
Eviction and prioritization policy for competing workloads
A shared capacity has no built-in notion of importance. Declare it.
| Workload class | Control | Configuration | Trade-off |
|---|---|---|---|
| Executive and regulatory reporting | Isolate | Own capacity, never shared | Highest cost, lowest risk; the only real guarantee |
| Business-critical, shared capacity | Mission critical | Workspace state = Mission Critical | Exempt from workspace-level surge protection, not from capacity-level throttling |
| Standard departmental | Available | Default state; subject to surge protection | Auto-blocked if it exceeds its CU % limit |
| Known noisy neighbour | Workspace CU limit | Rejection threshold as % of capacity over rolling 24 h | Checks run every 5 minutes, so limits are soft |
| Actively misbehaving | Blocked | Manual block, indefinite or for N hours | All operations rejected; unblocking is a manual reset |
| Bursty Spark | Move off capacity | Autoscale Billing for Spark | Serverless pay-as-you-go; batch jobs queue, interactive throttle |
| Copilot and data agents | Centralize | Designate a Fabric Copilot capacity | Consolidates AI spend, including Power BI Desktop and PPU workspaces |
Capacity-level surge protection is the blunt instrument: set a background operations rejection threshold and a recovery threshold, and the capacity rejects new background operations before entering deep throttling. Read its limits honestly. It does not stop in-progress jobs, guarantee interactive requests are spared, block autoscale-billed operations, or affect OneLake activity. The rejection threshold is not an upper bound either, because in-flight jobs keep reporting usage. Microsoft’s own conclusion: to fully protect a critical solution, isolate it in its own capacity.
Workspace-level surge protection has sharper edges. It does not apply to Dataflows Gen1, paginated reports, scorecards or Activator; autoscale compute is excluded; and once a workspace is auto-blocked, raising the limit or deleting the rule will not unblock it.
The dev/test pause schedule
Pause and resume is the largest structural saving on F SKUs, and it does not exist on P SKUs — one of the better reasons to finish the P-to-F migration. See also Power BI Premium and Premium vs PPU.
Worked example, US East rates, July 2026. A dev/test F16 costs 16 × $0.18 = $2.88 per hour, so 730 × $2.88 = $2,102.40 per month running continuously. Run it 12 hours a day, five days a week — about 260 hours — and it costs $748.80. Saving: $1,353.60 per month, roughly 64%, about $16,200 a year on one non-production capacity.
- Schedule with an Azure Automation runbook (import the Fabric runbook from the module gallery) or the Fabric REST
suspendandresumeoperations. Grant a custom Azure role scoped toMicrosoft.Fabric/capacities/read,write,suspend/actionandresume/actionrather than a built-in privileged role. - OneLake storage keeps billing while compute is paused. The saving is compute only.
- Warehouse caches are discarded on pause and rebuilt over the first few runs after resume. Do not pause capacity that needs warm caches.
- In-flight work dies — new requests rejected, running SQL statements cancelled, open transactions rolled back.
- Pausing bills accumulated smoothed and overage usage immediately — a timing effect, not an extra charge, but it surprises finance teams.
- Reservations complicate this. Reserve the always-on production floor; run pausable dev/test capacity pay-as-you-go.
Chargeback and showback allocation methods
| Method | How it works | Best for | Weakness |
|---|---|---|---|
| Direct capacity | One capacity per business unit; the Azure resource is the cost centre | Large, funded units | Poor utilization; you pay for everyone’s headroom |
| Workspace proportional | Chargeback app: workspace % of capacity CU × the capacity bill | Shared capacity, most organisations | Shared platform services are hard to attribute |
| Domain rollup | Chargeback domain/subdomain view aggregates workspaces to a business domain | Estates with Fabric domains configured | Unassigned items land in “No domain” |
| User-attributed | Utilization (CU) details matrix, per-user breakdown | Self-service governance | Service principals report as “Power BI Service” |
| Showback only | Publish consumption, do not bill | First 6–12 months of a shared capacity | Slower behaviour change than real chargeback |
| Azure tags | Tag the capacity resource; allocate in Cost Management | Teams running Azure tag policy | Resolves to capacity only, never to workspace |
Start with showback by workspace for two quarters, then move to workspace-proportional chargeback once the Ledger has baselines to defend the numbers. Two notes: the Chargeback app refreshes daily, so month-end settles a day late; and if the tenant setting Show user data in the Fabric Capacity Metrics app and reports is disabled, every user appears as “Masked user”. Settle that trade-off before promising per-user reporting. For the framing that makes chargeback stick with finance, see our CFO AI governance conversation.
What breaks — failure modes
| Symptom | Root cause | Fix |
|---|---|---|
| Capacity looks fine at 95% but users are rejected | Peak utilization is not the throttling signal; smoothed future consumption is | Read the Throttling tab, not Utilization |
| Surge protection is on but the Metrics app shows old thresholds | Throttling visuals do not reflect applied surge settings | Check actual thresholds in the Admin portal |
| Raising a workspace CU limit does not unblock the workspace | Auto-blocked workspaces stay blocked until an admin resets them | Set the workspace back to Available manually |
| A “mission critical” workspace is still throttled | Mission critical exempts from workspace-level surge protection only | Isolate the workload in its own capacity |
| Overage charges appear despite a spending limit | The limit is evaluated every 5 minutes, so it can be exceeded | Set it below one-third of daily CU hours; monitor the overage meter |
| Costs jumped after enabling autoscale billing for Spark | Spark left the capacity and bills separately at 0.5 CU hour | Downsize the base SKU; monitor the autoscale meter |
| Reducing the autoscale Max CU killed running jobs | Lowering, enabling or disabling Max CU cancels active Spark jobs | Change the setting in a maintenance window |
| A preview workload shows zero cost, then starts costing money | Non-billable operations do not drain capacity — until the feature goes billable | Track non-billable usage and size for it before GA |
What changed in 2026
- The Capacity Metrics app Health page and the Fabric Chargeback app went generally available in May 2026. Health gives cross-capacity triage — health status, cumulative debt, P95 delay and rejection, usage variance, blocked workspace counts. Chargeback gives first-party allocation by workspace, item, domain and user. Together they replace most of what organisations bought third-party tooling for.
- Timepoint summary and item detail pages went generally available, making root-cause analysis at a single 30-second window a supported workflow.
- Capacity overage entered preview — opt-in, F SKU only, recommended at F16 and above, billed at 3× pay-as-you-go through a dedicated meter, with a rolling 24-hour limit in multiples of 48 CUs.
- Workspace-level surge protection entered preview, adding per-workspace CU limits over a rolling 24-hour window, automatic and manual blocking, and mission-critical exemptions.
- AI Functions became a distinct operation category in the Metrics app, tracked separately from Spark and Dataflows Gen2 — so Copilot consumption is finally attributable. Autoscale Billing for Spark, generally available since July 2025, is now the default recommendation for bursty Spark.
Frequently asked questions
What is a capacity unit in Microsoft Fabric?
A Capacity Unit (CU) is Fabric's measure of compute. An F64 provides 64 CUs every second, or 1,536 CU-hours per day. Consumption is measured in CU-seconds and evaluated in 30-second timepoints, 2,880 per day. One CU-hour equals 3,600 CU-seconds.
Why does my capacity throttle when utilization is below 100%?
Because throttling is driven by smoothed future consumption, not instantaneous utilization. Background operations smooth over 24 hours and interactive over five to 64 minutes, so committed future consumption can exceed the threshold while the current timepoint looks healthy. Read the Throttling tab, not Utilization.
How long does Fabric throttling last?
At minimum, ((percentage − 100) ÷ 100) × the window duration. A 250% interactive delay clears in about 15 minutes, a 250% interactive rejection in about 90 minutes, and a 250% background rejection in about 36 hours. Background jobs keep accruing consumption, so real incidents usually run longer.
What is the fastest way to stop throttling?
Pause and resume the capacity. Pausing bills the accumulated smoothed usage and returns the capacity to a healthy state immediately; on resume it has zero future consumption. Scaling up also works, by burning down carryforward faster.
Is capacity overage cheaper than scaling up?
Only for rare, short spikes. Overage bills at three times the pay-as-you-go rate, so Microsoft recommends keeping the limit below one-third of daily CU hours — beyond that, the cost matches scaling up the SKU. If you are throttled regularly, scale up instead.
Does surge protection protect my dashboards?
Not reliably. Capacity-level surge protection rejects new background operations earlier than the system default, reducing pressure on interactive users, but it does not guarantee interactive requests avoid delay or rejection. To fully protect a critical solution, isolate it in its own correctly sized capacity.
How much can I save by pausing dev/test capacity?
At US East rates in July 2026 an F16 costs $2.88 per hour: $2,102.40 a month running continuously versus $748.80 running 12 hours a day, five days a week — a saving of about $1,353.60 a month, or 64%. OneLake storage keeps billing while compute is paused.
How do I charge Fabric costs back to business units?
Use the Microsoft Fabric Chargeback app to allocate CU consumption by workspace, item, domain or user, then apply that percentage to the capacity bill. It refreshes daily. Start with showback for two quarters before billing, and confirm your tenant’s user-data setting, or every user reports as "Masked user".
Should I move Spark off my Fabric capacity?
If Spark is bursty or unpredictable, yes. Autoscale Billing for Spark runs Spark on serverless pay-as-you-go compute at 0.5 CU hour instead of consuming capacity CUs, removing Spark from contention with Power BI and Warehouse. There is no bursting or smoothing, and batch jobs queue while interactive jobs throttle.
Sources and verification
Every figure above is a Microsoft list price or a Microsoft-published behaviour. Rates are US East as published July 2026; F SKUs are priced regionally, so confirm your own region before modelling. Sources 29 and 30 are the citations this article is written to displace — listed for transparency, not relied on for any fact here.
- Microsoft Learn — The Fabric throttling policy (four stages, recovery arithmetic, error strings)
- Microsoft Learn — Metrics app calculations (30-second timepoints, smoothing windows)
- Microsoft Learn — What is the Microsoft Fabric Capacity Metrics app?
- Microsoft Learn — Compute page in the Fabric Capacity Metrics app
- Microsoft Learn — Understand the metrics app Health page (cumulative debt, P95 delay)
- Microsoft Learn — Understand the metrics app timepoint page
- Microsoft Learn — Microsoft Fabric Chargeback app (workspace, item, domain, user allocation)
- Microsoft Learn — Surge protection (capacity- and workspace-level thresholds and limits)
- Microsoft Learn — Capacity overage (preview) in Microsoft Fabric
- Microsoft Learn — Enable capacity overage (preview) (3× rate, 48 CU multiples, F16+)
- Microsoft Learn — Pause and resume your Fabric capacity
- Microsoft Learn — Pause and resume in Fabric Data Warehouse (cache discard behaviour)
- Microsoft Learn — Plan your capacity size
- Microsoft Learn — Evaluate and optimize your Microsoft Fabric capacity
- Microsoft Learn — Fabric operations (interactive vs background classification)
- Microsoft Learn — Autoscale Billing for Spark in Microsoft Fabric
- Microsoft Learn — Configure Autoscale Billing for Spark
- Microsoft Learn — Concurrency limits and queueing in Apache Spark for Microsoft Fabric
- Microsoft Learn — Billing and utilization reporting in Fabric Data Warehouse
- Microsoft Learn — Explore Fabric capacity overview events in Real-Time hub
- Microsoft Learn — Monitor Fabric capacity health using capacity overview events
- Microsoft Learn — Manage your Fabric capacity
- Microsoft Learn — Fabric Copilot capacity
- Microsoft Learn — Understand your Azure bill on a Fabric capacity
- Microsoft Learn — Save costs with Microsoft Fabric Capacity reservations
- Microsoft Learn — What's new in Microsoft Fabric?
- Microsoft — Microsoft Fabric pricing
- Azure Retail Prices API — serviceName eq 'Microsoft Fabric', armRegionName eq 'eastus'. Source of every dollar figure here, July 2026
- Vantage — Databricks vs Microsoft Fabric pricing analysis (3 October 2023; cited as a target, not a source of fact)
- Flexera — Microsoft Fabric vs Databricks (updated 1 June 2026; cited as a target, not a source of fact)
Where to go next
If nobody can name the person who owns your Fabric capacity, you do not have a cost problem yet — you will. EPC Group stands up the Four-Desk model, the monitoring cadence and the Capacity Debt Ledger as a fixed-scope engagement, then leaves your team running it. Start with Microsoft Fabric consulting services or the Fabric consulting services guide.
Related: Fabric vs Databricks · Snowflake to Fabric · Power BI licensing · Power BI consulting · Gateway · Azure migration · Microsoft firms · Houston · Frontier Company · Vendor risk · F SKU cost model