Lesson 3 of 8 · 11 min
Diagnosing Throttling From the Capacity Down
A report takes twenty seconds to open. A pipeline that usually finishes before breakfast is still running. Someone sees utilization above 100% and proposes moving from F64 to F128.
That might turn out to be the right decision. It should not be the first one.
Throttling incidents are confusing for a structural reason: the item that users see failing is often not the item that created the pressure. Smoothing spreads a large background operation across the next 24 hours, so a refresh that finished at 3:00 AM can still be consuming capacity when the 10:00 AM report fails. If you start from the complaint, you investigate the victim. Start from the capacity instead.
Step 1: Separate slow from throttled
Slow and throttled feel the same to a user, but they are different problems.
A visual can be slow because its DAX is expensive. A warehouse query can be slow because it scans far more data than it needs. A Spark job can wait for executors. A gateway, a source system, a cold cache, or a lock can all add delay. None of these are throttling.
Throttling is specific: the capacity has consumed enough future compute to enter a protection stage. Confirm it on the Throttling tab of the Capacity Metrics app, and in System events on the Compute page. Rejected requests can also surface errors such as CapacityLimitExceeded.
If no throttling chart crossed 100% during the incident, stop treating it as a capacity problem and investigate the item. Buying capacity to fix a bad query is an expensive way to avoid reading its execution plan.
Step 2: Pin down the window and the stage
Record the time, capacity, workspace, symptom, and whether interactive work, background work, or both were affected. Start with the narrowest window that contains the incident.
Then note which stage was reached:
- Interactive delay means more than 10 minutes of future capacity was consumed.
- Interactive rejection means more than 60 minutes.
- Background rejection means more than 24 hours.
Check carryforward. A short surge that adds and burns down within the hour is a different incident from sustained demand that keeps adding debt all morning. Minutes to burndown estimates how long recovery would take if no new work arrived.
Step 3: Find the operations that consumed the CUs
In the item and operation matrix, filter to the window and sort by CU (s). Expand the top consumers to see the operation type. For a single bad timepoint, use the timepoint drill-through, which includes smoothed background operations that started earlier.
For each top consumer, capture:
- Workspace and item
- Operation type, and whether it is interactive or background
- CU-seconds and operation count
- User or service principal
- Rejected and failed counts
Step 4: Classify the shape
Most incidents fit one of four shapes. The shape decides the response.
| Shape | What the evidence shows | Likely response |
|---|---|---|
| One expensive operation | A single run dominates CU-seconds | Optimize the query, code, model, or data layout |
| Excessive frequency | A modest operation runs far more often than its data changes | Reduce how often it runs |
| High concurrency | Many acceptable operations overlap | Control concurrency, isolate, or scale |
| Sustained demand | Optimized work stays consistently high | Scale up or out deliberately |
Classifying first prevents random tuning. It tells you whether to make each operation cheaper, run fewer of them, move them elsewhere, or provide more compute.
Step 5: Recover, then fix
Recovery and repair are different decisions. During an active incident, two levers clear throttling quickly on an F SKU:
- Temporarily scale up, so the larger capacity burns down carryforward faster. Scale back down once the incident is over and you have a fix.
- Pause and resume, which clears accumulated future usage so the capacity accepts work again immediately. Content is unavailable while paused, and the outstanding smoothed usage is billed at the pause, so treat this as an emergency lever.
Neither lever repairs the cause. If the incident shape was “one expensive operation” or “excessive frequency,” the same incident will return on the next schedule.
An illustrative incident
The numbers below are fictional, chosen to show the method.
Users report report failures between 09:40 and 10:30 on a Monday. The Throttling tab shows interactive rejection above 100% from 09:35 to 10:20. The top interactive consumers in that window are ordinary report queries from several workspaces, none unusual.
The timepoint drill-through tells a different story. About 60% of each timepoint is background work, and most of it comes from one semantic model refresh scheduled at 06:00. The refresh history shows it was changed from daily to hourly the previous Friday, so seven refreshes had run by 10:00, each smoothed over 24 hours.
The shape is excessive frequency. The fix is to return the refresh to the schedule its source supports, then confirm with the owner whether an hourly requirement exists and, if so, design incremental refresh for it. Scaling up would have hidden the change until the next capacity filled.
Exercise: run a postmortem
Use your most recent throttling incident. If you have never had one, use the illustrative incident above and fill in what you would check.
Incident window:
Capacity and SKU:
User-visible symptom:
Confirmed stage (delay, interactive rejection, background rejection):
Carryforward peak and minutes to burndown:
Top item by CU-seconds in the window:
Operation type, interactive or background:
CU-seconds and operation count:
Owner:
Recent change to schedule, code, data volume, or users:
Shape:
[ ] One expensive operation
[ ] Excessive frequency
[ ] High concurrency
[ ] Sustained demand
Recovery action taken:
Repair action and owner:
How we will confirm the repair worked:Keep the completed worksheet. A folder of these becomes the best evidence you will have when someone asks whether the capacity is the right size.
Carry this forward
Three of the four shapes are fixed in the workload, not in the capacity. The next lesson goes engine by engine through the changes that reduce CU-seconds per operation and operations per day.