Capacity Usage on F4 SKU Despite Minimal Activity

[tolgakurt]

Hi everyone,

I'm currently using an F4 capacity in Microsoft Fabric. During the day, I only trigger one pipeline run, and apart from that, there is no other known activity initiated from my side.

However, when I monitor the Capacity Metrics, I consistently see a baseline level of Background CU% usage throughout the day. I’ve attached a screenshot showing the CU % over time, where you can see that the usage remains active even when no workloads (pipelines, reports, or dataflows) are being executed by me.

 I would like to understand:

• What services or processes might be consuming capacity in the background?

• Could there be automatic system-level processes (e.g., caching, optimization, telemetry)?

•  

Is there a way to identify exactly which artifacts (datasets, models, reports) are contributing to this background load?

• How can I reduce unnecessary usage to better optimize capacity?

Any insights or suggestions would be greatly appreciated!

Thank you in advance.

[v-karpurapud]

Hi @tolgakurt 

We have not yet received a response from you regarding your query if you find the response helpful, kindly mark it as the accepted solution and provide kudos, as this will aid other members with similar queries.

Thank You.

[v-karpurapud · Accepted solution]

Hi @tolgakurt 

Welcome to the Microsoft Fabric Community Forum.

Microsoft Fabric capacity uses a shared pool of compute units (CUs) to support services like Data Warehouse, Dataflows, Real-Time Analytics, and Power BI. Even if you manually trigger only one pipeline, background processes such as dataflow staging, telemetry collection, autoscaling smoothing, and artifact caching can still consume CUs throughout the day. A common source of this background usage is the DataflowsStagingWarehouse, which can remain active even after dataflows are paused or deleted especially when Gen2 dataflows are enabled. Additionally, Fabric’s autoscale smoothing keeps compute resources online briefly after a workload finishes to avoid performance delays, which means even short tasks can lead to extended CU billing.

1. How to Identify the Source of Background Load?
 

To identify which artifacts are contributing to background capacity usage in Microsoft Fabric start with the Capacity Metrics App. It shows CU consumption by workload and timestamp, helping you identify which services like Dataflows, SQL, or Power BI are active during unexpected usage. If you have access to Kusto, you can query the CapacityCpuPerWorkloadSummary table for detailed insights, including autoscale and carry-forward metrics. Also, check your workspace for any dataflows or notebooks that might be scheduled or auto-refreshing, as these can run in the background without manual triggers.

2. How to Reduce Unnecessary Usage?

To reduce unnecessary usage and optimize your F4 SKU, consider disabling dataflow staging or removing unused dataflows. If you're on a Pay-As-You-Go plan, pausing capacity during idle hours can help manage costs, though autoscale smoothing may still result in some billing. Use the Fabric SKU Estimator to confirm whether F4 is the right fit sometimes a slightly larger SKU can handle spikes more efficiently. Review workspace assignments to ensure only active workspaces are linked to your capacity, and turn off auto-refresh settings on datasets, reports, or notebooks that don’t need frequent updates. These steps can help you manage capacity more effectively and avoid unexpected usage.

For reference: Manage your Fabric capacity - Microsoft Fabric | Microsoft Learn
Understand your Fabric capacity throttling - Microsoft Fabric | Microsoft Learn

If this response resolves your query, kindly mark it as Accepted Solution to help other community members. A Kudos is also appreciated if you found the response helpful.

Thank you for being part of Fabric Community Forum.

Regards,
Karpurapu D,
Microsoft Fabric Community Support Team.