If you manage a Microsoft Fabric capacity, there’s a good chance your users have already experienced throttling — 20-second delays, rejected queries, or broken dashboards — without you even knowing. The root cause is usually a temporary CU spike that pushes the capacity past its limits. The fix? Capacity Overage — a zero-cost insurance policy that automatically absorbs those spikes before they impact users.

In this article, I’ll explain what happens without overage, how to enable it, and how to combine it with Surge Protection for comprehensive capacity resilience.

The Problem: What Happens Without Overage

Fabric uses a smoothing mechanism to spread compute (CU) consumption over time. When usage exceeds what the capacity can handle, throttling kicks in — and it gets progressively worse:

• 20-second delays on every interactive request. When smoothed usage exceeds 10 minutes of future capacity, Fabric adds a 20-second wait to every dashboard query, report load, and ad-hoc analysis. Users notice immediately.
• Full rejection of interactive workloads. Once the 60-minute threshold is breached, all interactive requests — report views, DAX queries, dataflow previews — are rejected outright. Users see error messages instead of data.
• Background jobs blocked for up to 36+ hours. At the 24-hour threshold, even scheduled refreshes, pipelines, and Spark jobs are rejected. Recovery can take 1.5× the overload window — meaning a capacity at 250% background rejection needs ~36 hours to recover, during which nothing runs.
• Cascading user frustration & lost trust. End users don’t see “CU exhaustion” — they see broken dashboards, failed refreshes, and unresponsive reports. Repeated incidents erode confidence in the platform and drive shadow IT.

The Solution: How Capacity Overage Helps

• Automatic throttling prevention. Overage kicks in the moment the interactive delay threshold (>100%) is crossed. It pays off excess CU debt so delays and rejections never reach the user.
• Zero standing cost. There is no charge for having overage enabled. You only pay when it actually activates — and only for the CU-hours that would have caused throttling.
• Admin-controlled spending limit. Set a rolling 24-hour CU-hour cap (in multiples of 48 CU). Once the limit is reached, standard throttling resumes — so costs are always predictable and bounded.
• Instant activation, no restart required. Overage becomes active within 5 minutes of enabling. No capacity pause/resume, no workspace migration. Toggle it on and it works.
• Works alongside Surge Protection. Overage handles interactive spikes; Surge Protection limits background job accumulation. Together they provide comprehensive capacity resilience.

Cost Perspective: Overage vs. Scaling Up

Overage charges at 3× the pay-as-you-go rate, but only for excess CU-hours actually consumed. For occasional spikes this is significantly cheaper than permanently over-provisioning by upgrading to the next SKU.

Rule of thumb: Keep the overage limit at ⅓ of your daily CU-hours — that is the break-even point with scaling up to the next SKU size.

Scenario	Without Overage	With Overage
Occasional spike (1–2× /week)	Users hit 20s delays or rejection; admins firefight manually	Auto-resolved; users unaffected; small pay-per-use charge
Major spike (e.g., month-end)	Hours of rejection; 36h+ recovery; escalations to IT	Overage absorbs burst up to limit; workloads continue; clear cost trail
Sustained overload	Throttled until optimized or scaled up	Buys time to react; doesn’t replace proper sizing — scale up if recurring

When to Use — and When Not

• Ideal for: Rare unexpected spikes, small routine overloads, business-critical dashboards that cannot tolerate delays, capacities shared across multiple teams.
• Not a substitute for: Persistent under-sizing (scale up instead), workload optimization, or dedicated capacity isolation for mission-critical workloads.

Surge Protection: Prevent Runaway Background Jobs

Surge Protection is a complementary capacity setting with two controls:

• Workspace Consumption (interactive + background): Set a per-workspace CU limit as a percentage of total capacity over a rolling 24-hour window. When a workspace exceeds the threshold, it is blocked and all operations are rejected. Each workspace can be tagged as:
  • Available (default): follows surge protection rules
  • Mission Critical: exempt from workspace-level blocking, keeps running during spikes
  • Blocked: all operations rejected (manual or automatic)
• Background Operations (background only): Set a background rejection threshold (e.g., 60%) so background jobs are rejected before the capacity enters deep throttling (normally at 100%). This frees up CU for interactive use and prevents long recovery times. Does not directly protect interactive requests.

Combined Strategy: Surge Protection + Overage

You can combine both features on a single capacity to protect specific workspaces from each other — for example, a development workspace from a production one, both on the same capacity:

1. Enable workspace-level surge protection with a CU % threshold per workspace.
2. Mark your critical workspaces as Mission Critical — they are exempt from workspace-level blocking.
3. Leave other workspaces as Available — they get auto-blocked before causing capacity-wide throttling.
4. Enable Capacity Overage — catches remaining interactive spikes for your mission-critical workspaces.

Result: Non-critical workspaces get blocked by surge protection before they can cause overage billing. Overage effectively only fires for mission-critical workspaces. Surge protection reduces overage activation frequency, keeping costs low.

Note: Capacity-level throttling still applies to all workspaces once CU limits are fully exhausted. Mission Critical status only overrides workspace-level surge protection, not capacity-level limits. Overage handles that gap.

Recommendation & How to Enable

Enable Capacity Overage on every production F16+ capacity with a conservative spending limit (⅓ of daily CU-hours). This provides a zero-cost insurance policy when idle and an automatic safety net when spikes occur — protecting user experience without requiring admin intervention.

1. Admin Portal → Capacity Settings → select your capacity
2. Expand “Capacity Overage” → toggle On
3. Set a 24h CU-hour spending limit (start conservative, e.g. 48–96 CU-hours)
4. Click Apply — active within 5 minutes
5. Monitor via Capacity Metrics app + Azure Cost Management