What it does

Fabric lets operations burst above the capacity's provisioned compute, then smooths the cost of that work across future time points. When smoothed usage runs far enough ahead of what the capacity can pay for, throttling kicks in — in stages, starting with delays and ending with outright rejection.

Key facts

• Time points are 30 seconds long. There are 2,880 of them in 24 hours.
• Interactive operations smooth over a minimum of five minutes and up to 64 minutes depending on how much they consume. Background operations smooth over a full 24 hours.
• Overage protection lets a capacity burn 10 minutes of future capacity before anything is throttled.
• Stage one, past 10 minutes of future capacity: new interactive operations get a 20-second delay at submission.
• Stage two, past 60 minutes: new interactive operations are rejected. Background operations still start and run.
• Stage three, past 24 hours: everything is rejected, interactive and background.
• Operations already in flight are never throttled. Anything submitted before throttling began runs to completion.
• Throttling is per capacity. Where an item on one capacity is consumed from another, the consuming capacity's throttle state decides.
• Users see CapacityLimitExceeded, "Your organization's Fabric compute capacity has exceeded its limits. Try again later", or "Cannot load model due to reaching capacity limits".
• Exceptions exist. Real-Time Intelligence skips the 20-second delay stage entirely and only starts throttling at the rejection phase. Almost all Warehouse operations are reported as background to get 24-hour smoothing. Eventstreams get their allocated CU reduced rather than being blocked.
• Compound throttling protection means a chained request is throttled once per participating capacity rather than at every hop. Semantic models querying other semantic models over DirectQuery, and DAX queries from paginated reports, support it.
• Bursting and smoothing don't apply when Autoscale Billing for Spark is on — Spark usage goes pay-as-you-go.
• Preview features can generate non-billable operations. Only billable operations count towards throttling.
• Capacity admins can set an email alert for the capacity hitting 100% of provisioned CU.

When to use / skip

This isn't optional configuration, it's the physics of the platform, and the practical job is knowing how to read it when a client says "Power BI is slow". The first thing to establish is whether they're actually throttled or whether one badly built model is slow on its own — Microsoft says as much in their own docs, and it's usually the model. Install the Capacity Metrics app on every capacity engagement before you need it, because retrofitting it during an incident wastes the hour you need for diagnosis.

Configuration decisions

• Whether capacity is split so that data engineering and reporting don't share a throttle state.
• Whether capacity admins have the email alert for hitting 100% of provisioned CU configured, and who receives it.
• Whether the recovery play for an overload is a temporary SKU increase, a pause and resume, or just waiting for burndown.
• Whether capacity overage billing is enabled, which stops throttling at a premium rate — Microsoft documents it as 3x the normal capacity rate.
• On P SKUs, whether Autoscale is enabled, since that's the equivalent lever there.

Gotchas

• Going over 100% is not throttling. The Utilization chart shows spikes; the Throttling chart shows whether anything was actually delayed or rejected. People report the first as an incident and it usually isn't one.
• Background rejection at 24 hours takes refreshes down as well as reports. By the time you reach stage three you're in a genuine outage, and the way out is burndown, a bigger SKU, or a pause.
• Pause and resume is a legitimate self-service fix for throttling — it resets future capacity usage to zero — but it settles the accumulated overage onto the bill and takes all content offline while it's paused.
• Operations get classified as interactive or background at submission, before the system always knows what they are. Ambiguous cases fall back to background. So the Metrics app can look inconsistent with what you expected, and that's by design.
• The Metrics app shows rejected operations, but with very little detail — product, user, operation ID and submission time. They never ran, so there's nothing more to see.
• Microsoft explicitly reserves the right to change the throttling policy. Don't build a capacity plan that depends on the exact stage boundaries staying put.

Consultant notes

• Get the Capacity Metrics app installed and someone named as its owner during deployment, not after the first overload. It's the only tool that answers "what happened at 9am".
• The single most useful diagnostic habit is drilling to the time point and looking at which operations contributed. It's almost always a small number of items, and often one refresh overlapping the morning peak.
• Warn clients away from treating a bigger SKU as the first answer. Nine times out of ten the fix is a model that shouldn't be that big or a refresh that shouldn't run at 9am.
• Smoothing is genuinely good news and worth explaining. Clients who came from on-premises SSAS spend a lot of effort staggering jobs that Fabric would have handled for them.

---

Check again if the throttling stages or the smoothing windows are revised — Microsoft says outright they may change them.