Why are my reports slow while refreshes keep running?

Because Fabric throttles interactive operations first. The early throttling stages delay and then reject interactive queries — the ones behind report visuals — while background jobs like refreshes are only rejected in the most severe stage. So sluggish reports with healthy-looking refreshes is not a contradiction; it is exactly what early-stage throttling looks like.

Consumption dropped — why am I still throttled?

Overage carries forward. When the capacity spends beyond its CU budget it borrows from future capacity, and that debt must be burned down before throttling clears. Stopping the offending workload is necessary but not instant relief; recovery takes as long as the burndown, which is why prevention beats reaction.

Which operations count as interactive vs background?

Report queries and other on-demand user actions are interactive; scheduled refreshes, dataflows, notebooks and pipelines are background. The distinction matters twice: they are smoothed over different windows (minutes vs 24 hours), and they are throttled at different stages (interactive first, background last).

Fabric Capacity Throttling Explained

The symptoms arrive from users, not dashboards: reports spin, visuals time out, exports fail with capacity errors. The report gets the blame, but the cause is the capacity — something, somewhere on it, spent more compute than the SKU provides, and Fabric began defending itself. That defense is throttling, and it follows documented mechanics worth actually knowing.

Smoothing and burndown

Fabric never bills an operation at the instant it runs. Interactive operations are smoothed over a short window (minutes); background operations — refreshes, dataflows, notebooks — over 24 hours. When smoothed consumption exceeds the capacity’s CU budget, the excess is borrowed from future capacity (carryforward) and must be paid back — burned down — before the capacity is healthy again. Throttling severity is a function of how much future capacity you have already spent.

The throttling ladder

Under 10 minutes of future capacity consumed: overage protection — no throttling, the debt just burns down.
10 minutes to 1 hour: Interactive Delay — user-facing queries are artificially delayed (roughly 20 seconds); reports feel sluggish.
1 to 24 hours: Interactive Rejection — user queries are refused outright; background jobs still run.
Beyond 24 hours: Background Rejection — everything is refused, including refreshes. The capacity is effectively down.

Note what this design implies: by the time users feel anything, the capacity has already been overspending for a while — and because background smoothing spreads load across 24 hours, the operation that caused today’s throttling may have run last night.

Finding the offender

Diagnosis is a ranking exercise: per-item, per-operation CU consumption around the throttling window, split interactive vs background. The usual culprits, in order of frequency: scheduled refreshes piled onto the same hour, a runaway dataflow or notebook, one oversized semantic model doing full loads, and genuine interactive load growth. The Capacity Metrics app holds this detail — for about 14 days, which is fine for yesterday’s incident and useless for "this keeps happening every month-end".

Fix patterns

Spread refresh schedules — the 08:00 pile-up is the most common self-inflicted throttle.
Convert heavy full refreshes to incremental.
Retire zombie datasets that refresh for nobody.
Isolate dev/test and heavy engineering workloads from the reporting capacity.
Only then consider the next SKU — see the FinOps guide before doubling the bill.

Per-item history, kept long enough to matter

PGR Sonar stores timepoint-level capacity consumption per item and operation as long-term history, so throttling forensics work over months: what the utilization looked like around any past incident, which items dominate month after month, and whether the fix actually held. Capacity Diagnostics turns the same data into concrete recommendations — the specific datasets, dataflows or notebooks to reschedule or optimize before the next incident.

Fabric Capacity Throttling: How It Works and Finding the Culprit