Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/06-capacity-and-performance/feature-surge-protection.md
feature-surge-protection.mdv1 · history
CurrentApplies to ServiceUpdated 17 hours agoSource Microsoft Learn ↗

What it does

Surge protection stops background work from eating the compute that interactive users need. At capacity level it rejects new background operations once the capacity's 24-hour background percentage crosses a threshold you set, before it drifts into deep throttling. A workspace-level version (preview) caps what any single workspace can burn, and can block the offender.

Key facts

  • Capacity level uses two thresholds: a background rejection threshold (surge protection switches on) and a background recovery threshold (it switches off when the 24-hour background percentage drops below it).
  • The 24-hour background percentage is smoothed committed utilisation projected over the next 24 hours. You'll find it on the Capacity Metrics app Compute page, under Throttling on the Background rejection chart, and in Real-Time hub capacity events.
  • Without surge protection, a capacity lets that percentage reach 100% before rejecting new background operations.
  • Enable it in the Fabric admin portal under Capacity settings, then Surge protection. Set Background Operations to On, set both thresholds, Apply.
  • It supports Fabric SKUs only. In-progress jobs aren't stopped, so the rejection threshold isn't a hard ceiling. Autoscale-billed operations and OneLake activity are unaffected.
  • Some requests started from the Fabric UI are billed as background and get rejected too while it's active.
  • Workspace-level (preview) sets a CU limit per workspace as a percentage of the capacity, over a rolling 24 hours. Each workspace is Available, Mission critical (exempt from workspace rules, still subject to capacity throttling) or Blocked.
  • A blocked workspace rejects interactive and background operations. Block can be indefinite or for a set number of hours.
  • Workspace-level rules don't cover Dataflow Gen1, paginated reports, scorecards, graph model or Activator, and Dataflow Gen2 refreshes are blocked but editing isn't covered. Usage is checked every five minutes, so treat the limit as soft.
  • Notifications (banner and email) can be set at both levels.

When to use / skip

Use capacity-level on any shared capacity where interactive reporting sits alongside heavy refreshes and someone has already been burned by a throttling incident. Skip it where 80-90% of utilisation is background anyway: Microsoft's own guidance is that it won't help there, and you'll just reject your own refreshes. Treat workspace-level as a pilot until it leaves preview.

Configuration decisions

  • Rejection and recovery thresholds, set from what the Metrics app shows for that capacity, not from a default.
  • Which workspaces are Mission critical.
  • Workspace CU limit and block duration, if you pilot the preview.
  • Who receives the banner and email notifications.

Gotchas

  • Surge protection moves the pain; it doesn't remove it. Background jobs get rejected, which means refreshes fail, so the people who feel it are the data owners.
  • Mission critical doesn't protect a workspace from capacity throttling once the capacity itself is out of CU.
  • The workspace rule runs on a rolling 24 hours. When a four-hour block ends, the workspace can be blocked again straight away if its trailing total is still over the line.
  • Raising the limit or deleting the rule doesn't unblock a workspace. Change the limit, then unblock it (optionally forgiving recorded consumption).
  • Pausing an overloaded capacity can leave a spurious NotOverloaded event in System events. The capacity is still paused.

Consultant notes

  • Don't set thresholds blind. Spend an hour in the Metrics app first, then pick a rejection threshold between the usual peaks and the level where interactive rejection starts.
  • Tell the refresh owners before you turn it on. A rejected overnight refresh looks like a broken pipeline, not a capacity policy.
  • If a client has one workload that genuinely can't be interrupted, give it its own capacity. Surge protection is a tuning aid, not isolation.
  • Workspace limits are a useful conversation-starter with the team whose dev workspace keeps eating production headroom.

Revisit when workspace-level surge protection reaches GA or the supported item list changes.

Was this accurate?
Related
Capacity management and throttling06-capacity-and-performanceSubscriptions and alerts05-service-and-workspacesRefresh limits and scheduling06-capacity-and-performanceFabric capacity and F SKUs06-capacity-and-performanceAdmin portal and monitoring08-governance-and-securityScheduled refresh03-power-query-and-dataflows