Last updated: November 11, 2026
By ZapAI Team
Fabric capacity throttling is what happens when the work on a Microsoft Fabric capacity borrows more compute from the future than the SKU can repay. Fabric first delays new report queries, then rejects them, then rejects scheduled jobs too. The Capacity Metrics app shows which item caused it. A short list of settings decides whether you get throttled, billed extra, or warned in time.
Fabric capacity throttling starts once smoothed usage fills the next 10 minutes of capacity. New interactive work then waits 20 seconds, gets rejected past 60 minutes, and everything new is rejected past 24 hours, until idle capacity burns the debt down.
Small capacities feel this first. An F2 or F8 shares one modest pool across every refresh, notebook, report click and Copilot prompt. One heavy job at the wrong hour and the sales dashboard spins. Then the ticket arrives. “Fabric is slow.”
This guide is for whoever gets that ticket, whether that’s the BI manager, the data engineer or the IT admin who also owns the Azure bill, and it covers how capacity units and smoothing work, which Capacity Metrics page answers which question, a triage sequence for slowness, and the cost levers that sit around all of it. Every product fact was checked against Microsoft Learn in November 2026, a week before Ignite.
How Does Fabric Capacity Work?
A Fabric capacity is a pool of compute measured in capacity units, or CUs, where an F2 has 2 CUs, an F64 has 64, and every workload in the assigned workspaces draws from the same pool. Throttling applies per capacity.
Think of CUs as a budget per second. An F2 gets 172,800 CU seconds a day. Each operation converts its raw compute into CU seconds at a published rate. Spark, for example, maps one CU to two vCores. On an F2 that daily budget sounds generous until a single unoptimized Dataflow Gen2 refresh, a notebook someone forgot to stop and a dozen report users at month end all draw from it at the same time.
Microsoft splits every operation into two types, per its Fabric operations reference. That split matters more than anything else here.
| Type | Typical operations | Smoothed over |
|---|---|---|
| Interactive | Report visual queries, slicer clicks, XMLA reads, paginated report views, SQL database usage | At least 5 minutes, up to 64 |
| Background | Semantic model refreshes, Dataflow Gen2 runs, pipelines, notebooks, Spark jobs, warehouse queries, Copilot, data agents | 24 hours |
Two surprises live in that table. Warehouse queries count as background. So do notebook runs, even when someone runs one by hand.
New to workloads and OneLake? Start with our Fabric architecture explainer.
What Are Bursting and Smoothing?
Bursting lets one operation use more compute than the SKU provides, so it finishes fast. Smoothing then spreads the cost across future 30-second timepoints. Interactive work spreads over 5 to 64 minutes. Background work spreads over 24 hours.
Here’s the example from Microsoft’s throttling and smoothing documentation. A background job uses 1 CU hour on an F2. That’s six times what an F2 has in 10 minutes. Smoothing spreads it over 2,880 timepoints. Each one carries about 2.1%. No throttling. The same logic explains why Microsoft classifies so much work as background, because a 24-hour window lets heavy jobs run whenever they need to without forcing your team to choreograph every schedule around a small capacity.
Now the catch. Smoothed usage stacks. Every refresh, notebook and Copilot prompt from the past 24 hours is still being paid off in the current timepoint, which is exactly why a capacity can idle at 70% overnight with nobody signed in and then tip over the moment the morning report rush arrives.
One exception. With on-demand billing for Spark turned on, Spark jobs leave the capacity. Bursting and smoothing stop applying to them.
When Does Fabric Capacity Throttling Start?
Not at 100%. Fabric measures how much future capacity your smoothed usage has already claimed. Up to 10 minutes is free overage protection, and past that, throttling escalates in three stages.
| Future capacity already used | Stage | What users feel |
|---|---|---|
| Up to 10 minutes | Overage protection | Nothing |
| 10 to 60 minutes | Interactive delay | New report queries wait 20 seconds |
| 60 minutes to 24 hours | Interactive rejection | New report queries fail, background jobs still start |
| Over 24 hours | Background rejection | New requests fail, refreshes included |
Thresholds are from Microsoft Learn, November 2026. Microsoft says the policy may change.
Watch the last row. The throttling page says Fabric rejects all requests. The Capacity Metrics compute page says user-scheduled background jobs are rejected. Two Microsoft pages, slightly different scope. Plan for the stricter one. In practice that means assuming your overnight refreshes, pipeline runs and Spark jobs will all fail to start once a capacity crosses the 24-hour line, and building alerts so someone hears about it before the business does.
Carryforward and burndown
Usage above the SKU in a timepoint becomes an overage. Past the 10-minute window, it turns into carryforward. Later timepoints with spare room pay it back. That’s burndown. Throttling lasts until carryforward hits zero. If the debt is large, burndown on a small SKU can take hours, because an F2 only has 2 CUs of spare room per second to pay back whatever the busy hour borrowed from the rest of the day.
Some rules ease the blow. In-flight operations aren’t throttled. Real-Time Intelligence skips the 20-second delay stage entirely. Eventstreams get fewer CUs instead of stopping. Failed and canceled operations still count, though.
Rejected users see a CapacityLimitExceeded status, or a message that the model can’t load due to reaching capacity limits. Ask for that text.
Which Capacity Metrics App Page Tells You What?
The Microsoft Fabric Capacity Metrics app is a Power BI app that capacity admins install from AppSource. Version 3.0 ships two reports. The default report is generally available, and a redesigned report is in preview.
We use the default report for incidents, since Microsoft’s troubleshooting guide is written against it. Here’s which page answers which question, per the Capacity Metrics app overview.
| Your question | Where to look | What to read |
|---|---|---|
| Is any capacity in trouble? | Health page | Capacities ranked by compute, throttling and rejections |
| Did we pass 100%, and when? | Compute page, Utilization tab | Columns above the CU % Limit line |
| Did that actually throttle anyone? | Compute page, Throttling tab | Delay and rejection charts above 100% |
| How deep is the debt? | Compute page, Overages tab | Add, burndown and cumulative carryforward |
| When did throttling or surge protection start? | Compute page, System events | InteractiveDelay, InteractiveRejected, AllRejected, SurgeProtectionActive |
| Which item burns the most? | Compute page, item matrix | CU (s), plus Rejected count and Overloaded minutes |
| Who ran what in that 30 seconds? | Timepoint page | Tables sorted by Timepoint CU (s), with User |
| How long until recovery? | Timepoint page, burndown table | Minutes to burndown |
| Which operation type drove it? | Timepoint summary page | Totals by operation type |
| What did one item do? | Timepoint item detail page | Filters for operation ID, user, CU |
| What did on-demand Spark cost? | On-demand Compute for Spark pages | Spark billed outside the capacity |
Some details trip people up. The compute page holds 14 days. Data lands 10 to 15 minutes late. New items may wait for the nightly refresh. And the app has no alerts.
Two more from the compute page reference. Utilization over 100% doesn’t by itself mean throttling. And the throttling chart thresholds ignore your surge protection settings.
Install the app in a Pro workspace, off the capacity it monitors. Microsoft recommends that so the app isn’t throttled mid-incident.
What Should You Do When Users Report Slowness?
Confirm before you scale. Microsoft says slow performance is frequently down to item design, not throttling. Check utilization, then throttling, then the timepoint.
This sequence follows Microsoft’s three-stage report slowness troubleshooting guide, plus two steps we add.
- Get the workspace, report and exact time.
- Ask for the error text.
- Open the Compute page, pick the capacity, select that day on the ribbon chart, and zoom the Utilization tab to the window.
- Under 100% throughout? Stop. Hand it to the report developer.
- Over 100%? Open the Throttling tab.
- No chart above 100% then? Not throttling.
- Chart above 100%? Drill through to the Timepoint page.
- Sort both tables by Timepoint CU (s).
- Note the item, user, operation ID and % of base capacity.
- Read Minutes to burndown, then pick one fix and log it.
Step four ends plenty of tickets. Fast. Step two matters more than it looks, because a user who pastes the exact CapacityLimitExceeded text has just saved you half the investigation and hinted at which throttling stage they hit.
How do you read step eight? One huge background row usually means a refresh or Spark job, while dozens of mid-sized interactive rows usually mean a heavy report that every sales rep opened at once after the Monday meeting.
Need throttling gone now? On an F SKU, Microsoft lists three moves. Scale up temporarily, pause and resume, or lean on capacity overage. Each costs money.
How Do Surge Protection and Workspace Limits Help?
Surge protection rejects new background jobs earlier than Fabric would, so refreshes can’t push report users into rejection. Workspace-level surge protection, still a preview, caps what one workspace can consume per rolling 24 hours.
At the capacity level you set two numbers. A rejection threshold compares against the 24-hour background percentage. A recovery threshold decides when background work resumes. Without it, that percentage climbs to 100% before anything is rejected. Set the rejection threshold too low and you throttle your own pipelines for no reason, set it too high and interactive users stay exposed, so expect to tune it once or twice after watching a couple of weeks of real charts.
Microsoft’s surge protection guide says to read the Background rejection and Interactive rejection charts first, then set the rejection threshold between your typical background peaks and the level where interactive rejection began, and it warns that surge protection doesn’t stop in-progress jobs or guarantee interactive users stay safe. F SKUs only.
Workspace limits are sharper. You set a percentage of capacity per rolling day. On an F2, 5% equals 2.4 CU hours. Cross it and the workspace is blocked, indefinitely or for set hours. States are Available, Mission critical or Blocked.
Mind the fine print. Fabric checks every five minutes, so limits are soft. Mission critical skips workspace rules, not capacity throttling. And the window doesn’t reset after a block.
Who deserves Mission critical? Our view is finance close models and executive dashboards. Sandboxes stay Available.
Should You Turn On Capacity Overage or On-Demand Spark Billing?
Capacity overage pays off throttling-level usage at three times the pay-as-you-go rate, up to a rolling 24-hour threshold. It’s generally available and on by default for new F SKU capacities. On-demand billing for Spark moves Spark jobs to a separate pay-as-you-go meter.
Read that again. A capacity created today starts with overage on and a default threshold of 25% of daily CU hours. Great for users. Surprising for finance. We check it first on every new client capacity. By our arithmetic, an F2 has 48 CU hours a day, so the default 25% threshold allows about 12 CU hours of overage per rolling day, billed at three times the normal rate if it ever gets used.
Per Microsoft’s capacity overage overview, the threshold you set isn’t a hard cap, because Fabric evaluates it every five minutes and running work continues, so charges can land above it. It adds no speed or memory. It only removes delays and rejections.
Microsoft suggests keeping the threshold under one third of daily CU hours, roughly where overage costs what a bigger SKU would, and setting surge protection at 100% if you don’t want overage admitting new large background jobs. Turn overage on mid-incident and Fabric bills the accumulated carryforward at once.
For production, our practice keeps overage on, with a threshold well under the one-third line and notifications wired up, while dev and test capacities get it switched off because a throttled sandbox costs nothing and a surprise overage line on the invoice costs a conversation with the controller. The overage notifications are still a preview.
On-demand billing for Spark, which some Microsoft pages still call Autoscale Billing for Spark, is different. You opt in per capacity and set a maximum CU limit. Spark then runs on serverless compute billed at the Spark rate, without bursting or smoothing. At the limit, interactive Spark is throttled and batch jobs queue. See Microsoft’s on-demand billing for Spark page.
It suits bursty notebooks. Steady nightly ETL belongs on reserved capacity.
When Should You Scale, Pause or Reserve Capacity?
Scale up when throttling is regular. Pause when nobody needs the capacity. Reserve once a month of metrics shows a stable baseline.
Scaling happens in the Azure portal. Going up from below F64 is near instant. Crossing the F256 and F512 boundary can cancel running jobs, so schedule it. Don’t resize constantly.
Pausing ends throttling at once. Microsoft’s pause and resume guide says the remaining overages and smoothed operations are summed and added to your Azure bill when you pause, and content goes offline. Resume starts from zero. Runbooks or the REST API can schedule both. Pausing is a great habit for development capacities that sit idle overnight and on weekends, and a poor emergency button for production, because the bill for everything already smoothed into the future arrives the moment you press it.
Reservations come in single-CU increments for one or three years, applied hourly. Unused reserved hours are lost. Scaling below the reservation doesn’t cut the bill, and usage above it bills at pay-as-you-go, per Microsoft’s Fabric capacity reservations page. Because the discount applies per hour and never carries over, a reservation sized for your busiest month wastes money in every quiet hour, which is why we size from at least a month of measured usage rather than a vendor estimate.
Prices and break-even live in our Fabric vs Power BI Premium buying guide. No need to repeat them.
A pattern we like for small estates? Reserve the production baseline. Pause a pay-as-you-go dev capacity nightly. Let overage absorb rare spikes.
How Much Capacity Do Copilot and Data Agents Use?
Copilot in Fabric costs 100 CU seconds per 1,000 input tokens, 10 for cached input and 400 per 1,000 output tokens. Data agents use the same rates under the AI Query operation. Both are background, smoothed over 24 hours.
Microsoft’s Copilot consumption page prices a sample request of 2,000 input and 500 output tokens at 400 CU seconds. On an F64, that’s over 13,000 requests a day. Our arithmetic on an F2 gives roughly 430. Before any refresh runs. That’s a few hundred average questions a day on the smallest SKU, shared with every refresh and report on the capacity, which is why we pilot Copilot with one team before anyone switches it on for the whole company.
Generated DAX or SQL bills separately to the engine that runs it, and instructions, example queries and chat history all count as input tokens too, per Microsoft’s data agent consumption page. Look for Copilot in Fabric, AI Query and the LlmPlugin item kind in the app.
Our Copilot in Power BI guide covers the separate Copilot capacity option. Our Fabric IQ and data agents explainer covers what agents do.
Which Tuning Fixes Cut CU Use the Most?
Fix the top three items in the matrix before touching the SKU. In our experience the culprits repeat. Idle Spark sessions, dataflows that don’t fold, stacked refreshes, and Direct Lake falling back to DirectQuery.
Spark sessions and pools
Sessions hold compute until they time out. Shorten the workspace timeout. Stop sessions when done. Size pools small for small jobs. Per the Spark concurrency and queueing page, an F2 has 4 Spark vCores with a burst ceiling of 20, and a throttled capacity rejects new Spark jobs rather than queueing them. Admins can also disable job-level bursting. On small SKUs the waste we see most is an interactive notebook session left running over lunch, quietly holding vCores that a scheduled pipeline then can’t get, which ends in an HTTP 430 error nobody connects to the notebook.
Dataflow design and query folding
Folding pushes filters and joins back to the source. Less data moves. Microsoft’s Dataflow Gen2 performance best practices also recommend Fast Copy, staging non-folding steps in a second query, incremental refresh and the Modern Evaluator. Our dataflow vs pipeline vs notebook comparison has the CU math.
Semantic model refresh scheduling
Refreshes smooth over a day. Stacked, they still raise the floor every report query lands on. Stagger them. Use incremental refresh. Stop hourly refreshes on weekly reports. A model refreshed every hour from 6 a.m. to 6 p.m. runs twelve times a day, and if half of those runs land on top of other models, the background floor rises right as people open their reports. Our Power BI services team does this tuning routinely.
Direct Lake fallback
Direct Lake on SQL endpoints falls back to DirectQuery for SQL views, SQL row-level security, or exceeded guardrails. Direct Lake on OneLake doesn’t fall back. Per the Direct Lake overview, F2 through F8 allow 300 million rows per table and a 10 GB model. Optimize Delta tables before buying a bigger SKU. Fallback is easy to miss because reports keep working, just slower, so the only clue may be SQL endpoint query activity in the metrics app where you expected cheap in-memory queries. Our lakehouse vs warehouse guide covers the source side.
What Does a Weekly Capacity Routine Look Like?
About 30 minutes a week covers a small estate. That’s ZapAI practice, not a Microsoft rule, sized for one admin and an F2 to F64.
Weekly
- Health page first.
- Throttling tab, last seven days.
- Top five items by CU (s), compared with last week.
- Performance delta in orange or red.
- System events for surge states.
- Overage meter in Azure Cost Management.
Monthly
- Average and peak utilization against the SKU.
- Surge thresholds re-tuned.
- Copilot and AI Query trends.
- Scale, split or reserve decision.
Always on
- Activator alert on capacity state.
- Overage and throttling emails.
- Limits on sandbox workspaces.
Why Activator? The metrics app can’t alert. Real-Time hub’s capacity overview events emit a summary every 30 seconds and a state event when a capacity becomes overloaded, paused or resumed, and storing them in an eventhouse keeps history well past the app’s 14 days, a pattern our Real-Time Intelligence guide walks through.
Which Mistakes Keep Causing Throttling?
These show up again and again in our capacity reviews. None are exotic.
- Production and dev on one F2.
- Overage left at default, unwatched.
- Scaling before reading the Throttling tab.
- Pausing a busy capacity without expecting the bill.
- Every refresh at 6 a.m.
- Copilot for everyone, no pilot.
- Reserving from a first-month guess.
- Metrics app on the monitored capacity.
- Treating workspace limits as hard caps.
Governance is the other half, from who creates workspaces to who assigns them to capacity. Our Microsoft Fabric primer covers basics, and a deeper governance guide is coming.
What Belongs on a Fabric Capacity Checklist?
Run this before go-live and each quarter.
- Metrics app installed and shared.
- Show user data setting reviewed.
- Overage threshold set deliberately.
- Surge protection tuned from charts.
- Sandbox workspace limits set.
- Mission critical used sparingly.
- State alerts flowing.
- Production and dev separated.
- Dev pause schedule running.
- Refresh schedules staggered.
- Spark timeouts reviewed.
- Top dataflows folding.
- Direct Lake fallback checked.
- Reservation sized from real usage.
Want help? Our Fabric data engineering services include capacity reviews.
What Could Change After Ignite 2026?
Possibly the preview pieces. Ignite runs November 17 to 20, 2026, in San Francisco, and we’ll watch workspace-level surge protection, overage notifications, the preview metrics report and Copilot rates there, then refresh this post within a couple of weeks.
Wrapping Up
Once you see the mechanics, Fabric capacity throttling is predictable. Smoothed usage piles up, throttling begins after 10 minutes of borrowed capacity, and burndown ends it. Read the Throttling tab before you scale. Drill to the timepoint before you blame a team. Then decide on purpose whether overage, surge protection and pausing belong on each capacity, because the defaults won’t decide well for you.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Microsoft Fabric consultants run capacity reviews, set up surge protection and alerts, and tune the reports, dataflows and notebooks behind the spikes. Ask us for a Fabric capacity review, and we’ll walk through your metrics app with you and leave a short list of fixes ranked by CU saved.
Questions Teams Ask About Fabric Capacity
Does 100% utilization mean my capacity is throttled?
No. Utilization over 100% means usage exceeded the SKU in that timepoint. Throttling starts only once smoothed usage fills the next 10 minutes. The Throttling tab confirms it.
How long does Fabric throttling last?
Until burndown pays off the carryforward. The Timepoint page estimates Minutes to burndown, assuming no new work. Scaling up or pausing ends it sooner, at a cost.
Does pausing a Fabric capacity save money during throttling?
Not really. Pausing stops throttling at once, but Microsoft bills the remaining smoothed usage and overages when you pause. It saves money on idle capacity, not on debt already run up.
Is capacity overage turned on by default?
Yes, for new F SKU capacities, with a default rolling 24-hour threshold of 25%. Overage bills at three times the pay-as-you-go rate, so review it on every capacity.
Can one workspace throttle the whole capacity?
Yes. Throttling applies per capacity, so one heavy workspace slows the rest. Workspace-level surge protection, in preview, can block a workspace that crosses its daily limit.
Do Copilot and data agents count against my Fabric capacity?
They do. Both consume CUs per token as background operations smoothed over 24 hours. Queries they generate bill separately to the engine that runs them.
Which Capacity Metrics page shows who caused a spike?
The Timepoint page. Drill through from a spike on the compute page, sort both tables by Timepoint CU (s), and read the User, item and operation ID columns.