Quick summary:
Reports that take an extra 20 seconds to open between 7 and 11 a.m., then behave normally by afternoon, are rarely a report design problem. They are the signature of Microsoft Fabric throttling: a capacity that has already spent its future compute. This case study covers how our team at ScriptsHub Technologies diagnoses that pattern on a shared F16 Microsoft Fabric capacity: why the Utilization chart hides it, which chart predicts user pain, and which four changes cut consumption without a larger SKU.
Why do Power BI reports slow down only in the morning?
Morning-only slowness across every report on a shared capacity often signals Microsoft Fabric throttling, not a modeling issue.
Complaints that follow the clock are diagnostic: a bad semantic model is slow all day, while Microsoft Fabric throttling affects a capacity under pressure only on a schedule. The setup is the one most teams reach within a year of adopting Fabric: one F16 running an overnight batch of low-code dataflows into a lakehouse, then serving a few hundred report users. Complaints cluster between 07:00 and 11:00, vanish by afternoon, and the Metrics app looks fine, so reports get rebuilt.
Three details mattered more than that rebuild. The delay hit every report equally, including one over a few thousand rows, which alone rules out report design. Several refreshes had failed overnight with a capacity limit error, not a data error. And the delay was consistent rather than variable: roughly 20 seconds, every time.
That last detail is the diagnosis: a fixed delay of exactly that length is a documented platform penalty, not a performance curve. Microsoft’s capacity throttling policy applies a fixed 20-second delay to interactive operations as its first phase, once a capacity has used up all its CU resources for the next 10 minutes. A repeatable delay of that length tells you which stage you are in.
Figure 1: Smoothed consumption against the 10-minute throttling threshold across a typical weekday, before remediation.
Why does the utilization chart look healthy while the capacity is throttled?
Fabric does not throttle on utilization. It throttles on how much of your future capacity your smoothed usage has already committed.
Two mechanisms create that gap. Bursting lets an operation temporarily use more compute than the SKU provides, so large jobs finish faster. Smoothing is the accounting counterpart: instead of charging a spike to the moment it happened, Fabric spreads CU usage across future 30-second timepoints, 5 to 64 minutes for interactive operations and 24 hours for background work.
The consequence is easy to miss. An overnight batch does not stop costing you anything when it finishes; its CU cost keeps landing on every subsequent timepoint all day. Utilization at 09:00 looked modest because the spike had been flattened. What the chart hid was that the flattened cost had spent the next 10 minutes of capacity, the line that triggers a penalty. Because utilization over 100% does not by itself mean trouble, the Fabric Capacity Metrics app carries a separate Throttling chart. Read that one.
One exception voids all of the above: bursting and smoothing do not apply when a capacity admin enables Autoscale Billing for Spark, which moves Spark onto serverless pay-as-you-go compute outside the capacity. This case assumes the standard model.
What are the Microsoft Fabric throttling stages?
Fabric grants 10 minutes of future capacity as overage protection before any penalty, then escalates through three stages sequenced so data refreshes outlast dashboard queries.
This is where the common retelling goes wrong. Overage protection is often called the first of four stages. It is closer to the opposite: the buffer that stops short spikes reaching a stage at all.
Microsoft Fabric throttling is what happens when operations consume more CU seconds than the SKU allows, measured after smoothing. Confirm it from the error text: a throttled capacity returns the status code CapacityLimitExceeded, and users see either that Fabric compute capacity has exceeded its limits, or that a model cannot load because it reached them. Anything already running is safe: throttling applies only to requests submitted after it began, so in-flight jobs complete.
Behavior varies by workload: Real-Time Intelligence skips the delay stage until rejection at 60 minutes; Fabric classifies almost all Warehouse operations as background, so they get 24-hour smoothing instead of tripping thresholds on every peak.
Figure 2: Escalation stages, each measured against committed future capacity.
How do you diagnose throttling in the Capacity Metrics app?
Read the Throttling chart first to confirm a threshold breach, then drill through to the worst timepoint to find out what caused it.
Our team follows a fixed sequence, each step ruling out a class of cause. Confirm the symptom is time-bound. Check whether refresh failures carry a capacity limit error. Open the Throttling chart and read your position against each threshold as a percentage, since that determines whether anyone feels anything. Then drill into the timepoint.
That drill-through is the step teams skip, and the one that ends the investigation. Clicking a timepoint returns the responsible operations ranked by CU seconds, plus rejected ones that would leave no trace.
Figure 3: A repeatable diagnostic sequence for Fabric capacity throttling.
Which workloads drive the morning load?
Four findings account for the morning load in this scenario: engine choice, batch timing, refresh frequency and Spark pool sizing. None is a function of SKU size.
The dataflow finding needs precision, because the old flat-rate shorthand misleads. Dataflow Gen2 pricing rates a non-CI/CD item at 16 CU across the whole query duration; a CI/CD item uses two tiers, 12 CU per second up to 10 minutes then 1.5 CU beyond. Staging adds 6 CU per second of SQL engine time on top. The meter runs on duration, so a complex merge running 8 minutes bills the same whether it moved 4,000 rows or 4 million. Routing ingestion through OneLake shortcuts leaves only the transform cost.
The drill-through surfaces all of it in about 90 seconds; the utilization chart shows none of it.
How do you fix Microsoft Fabric throttling without upgrading the SKU?
Fix Fabric capacity throttling by cost of change rather than size of gain, so the cheapest fixes go first and you can measure whether anything more invasive is needed.
The first change matches refresh frequency to when data actually arrives, the fastest win and one requiring no rearchitecture. The second staggers the overnight batch instead of firing every job at 02:00. The third moves the heaviest transforms into notebooks, where watermark-driven incremental patterns bill against vCore-hours. The fourth sizes Spark pools against the job.
That last one is worth showing as arithmetic, because the intuition runs backwards.
Why this works. CU cost is vCore-hours, not wall-clock time. Under Spark capacity billing, every CU purchased translates to two Apache Spark vCores, so halving the core count and accepting a 38% longer runtime still lands roughly 30% cheaper: cores came off every second of the job. That runtime penalty is an assumption, not a measurement: halving cores rarely costs exactly this much wall-clock time, and your figure moves with the job’s shuffle profile. The direction holds where the magnitude may not. Faster is not automatically cheaper, and that distinction disappears if runtime is the only thing you measure on a Spark-based incremental load.
If your Fabric bill is climbing, or reports slow on a schedule nobody can explain, that sequence is our work. Our data engineering team runs CU consumption reviews across the US, UK, and India, and the outcome is usually a schedule change, not a purchase order. Start a conversation.
How do you confirm throttling has actually stopped?
Wait a full day before judging the result, because background operations smooth across 24 hours and a pipeline change cannot show its effect on the afternoon you ship it.
Carryforward accumulated before the change masks it longer still. Enforcement continues until unused capacity pays off all carryforward CUs, a process called burndown, so until then the charts show the old problem.
Figure 4: The same weekday profile after remediation, compared against the original.
Measured a day apart, the morning peak settles clear of the threshold, the 20-second delays stop, and the overnight refresh failures end. No SKU change is needed. Scaling the capacity would absorb the symptom while leaving every inefficiency in place and billed for permanently.
What this generalizes to on any Microsoft Fabric capacity
Alert on threshold percentages rather than utilization, and treat engine choice as the largest single lever you have on CU cost.
Utilization above 100% is normal and often harmless, because bursting is designed behavior, not a fault. A breach is neither. Alerting on the wrong number gives noise or silence, and either way the chart goes unread.
Engine choice matters more than teams expect. The same transformation can differ by an order of magnitude in CU cost depending on the engine, and that call is usually made once, early, by whoever was nearest the tools. Revisiting it costs a sprint. Resizing costs every month until somebody revisits it anyway.
Surge protection does not add compute. It caps what the capacity may spend, rejecting background work before a spike throttles.
Capacity overage does add compute, but bills it at three times the pay-as-you-go rate up to an admin-set 24-hour limit, and once that limit is hit standard throttling resumes. It is in public preview at the time of writing, F SKUs only, and recommended during preview for F16 and higher. Neither substitutes for removing the work.
Capacity Units are counter-intuitive in one way: the number determining whether users suffer is not the one shown by default.
ScriptsHub Technologies helps data teams restore Microsoft Fabric performance and right-size capacity before renewal. Talk to our team, or see how we work across the Microsoft data platform.
Frequently asked questions
Q. What is Microsoft Fabric throttling?
Throttling is Fabric delaying or rejecting new operations because smoothed usage has consumed more CU seconds than the SKU allows. It escalates through interactive delay, interactive rejection, then background rejection.
Q. What are the known issues with Microsoft Fabric?
Capacity throttling is the most common. Smoothing spreads background cost across 24 hours, so the Utilization chart looks healthy while every user waits 20 seconds on each interaction.
Q. What are the downsides of Microsoft Fabric?
The shared capacity model is the main one. Batch pipelines and business-hours reporting draw from one CU pool, so an overnight load can throttle morning reports with no chart showing a problem.
Q. When not to use Microsoft Fabric?
Avoid one shared capacity when heavy ETL and interactive reporting compete for the same CUs and cannot be staggered. Separate capacities, or a cheaper transform engine, cost less than constant throttling.
Q. How do I stop Fabric capacity throttling immediately?
Two levers work on F SKUs. Scaling up temporarily burns carryforward down faster, since each timepoint gains headroom. Pausing and resuming clears it at once, but bills accrued overage and takes content offline.
