Forum Discussion
Background CU used in Fabric Capacity Metrics
I'm trying to manage the CU usages to lower my billing.
My system has 2 main orchestrators to process data for my 2 reports. One will run every 15min and other is 8h. Both will use copy activity to retrieve data from 42 data sources (using ForEach) and then using notebook to process later on.
I was previously using an F62 capacity. Based on my observations in the Job tab under Spark Settings, my max workload was only taking around 88/192 CUs (when there was 2 15m orche and 1 8h orche running in the same time), so I decided to scale down to F32.
After the downgrade, my system became unresponsive and started hitting capacity limits. My Power BI reports couldn't load, and I was forced to scale the capacity back up to F62.
Then, I discovered the Fabric Capacity Metrics app and noticed that my Background workload was consuming nearly 80% of the available CUs. What's strange is that many pipelines, activity, notebooks, and other jobs that had already completed more than 12 hours earlier still appeared to be consuming a small amount of capacity in the background.
Does anyone know how to troubleshoot or resolve these background activities? is there a way to identify or clear them?
Hi dinhhoa,
Check Fabric Capacity Metrics → Compute → Timepoint details to identify the operations with the highest Timepoint CU (s) and correlate them with the period when Power BI was affected. Completed background operations do not necessarily indicate active execution; Microsoft states that background operations completed within the previous 24 hours can continue contributing CU usage through smoothing. Review the pipeline's orchestration, Copy activity, and downstream Notebook consumption because all can contribute to the overall pipeline workload. Verify Interactive Delay/Rejection during the reported incident to confirm whether capacity throttling affected Power BI. Finally, use the observed CU consumption, throttling, and workload data to determine whether workload optimization or capacity adjustment is required.
Understand the metrics app health page - Microsoft Fabric | Microsoft Learn
Pricing for Pipelines - Microsoft Fabric | Microsoft Learn
Troubleshooting guide - Determine source of report slowness - Microsoft Fabric | Microsoft Learn
Metrics app calculations - Microsoft Fabric | Microsoft Learn
Understand the metrics app timepoint page - Microsoft Fabric | Microsoft LearnThank you.
6 Replies
v-saisrao-msftCommunity Support
Hi dinhhoa,
Check Fabric Capacity Metrics → Compute → Timepoint details to identify the operations with the highest Timepoint CU (s) and correlate them with the period when Power BI was affected. Completed background operations do not necessarily indicate active execution; Microsoft states that background operations completed within the previous 24 hours can continue contributing CU usage through smoothing. Review the pipeline's orchestration, Copy activity, and downstream Notebook consumption because all can contribute to the overall pipeline workload. Verify Interactive Delay/Rejection during the reported incident to confirm whether capacity throttling affected Power BI. Finally, use the observed CU consumption, throttling, and workload data to determine whether workload optimization or capacity adjustment is required.
Understand the metrics app health page - Microsoft Fabric | Microsoft Learn
Pricing for Pipelines - Microsoft Fabric | Microsoft Learn
Troubleshooting guide - Determine source of report slowness - Microsoft Fabric | Microsoft Learn
Metrics app calculations - Microsoft Fabric | Microsoft Learn
Understand the metrics app timepoint page - Microsoft Fabric | Microsoft LearnThank you.
- GilbertQ
Super User
Hi dinhhoa
What I would recommend doing is looking to see if there are ways to optimize your notebook code because even though it does not look like it is a lot individually, clearly it is consuming a lot of your background processes as it is sitting between 80 to 100 percent just for the running of the pipelines. Another option you could look at if the data is not extremely large, say less than 100 million rows. To convert the notebooks from Spark notebooks to Python notebooks. This could save new significant capacity consumption.
- v-saisrao-msft
Hi dinhhoa,
Have you had a chance to review the solution we shared earlier? If the issue persists, feel free to reply so we can help further.
Thank you.
- v-saisrao-msft
HI dinhhoa,
Checking in to see if your issue has been resolved. let us know if you still need any assistance.
Thank you.
- Kagiyama_yutaka
Skilled Sharer
If you don’t mind, could you add a little more detail about how your pipelines and notebooks are running? For example, it helps to know roughly how many activities are running at the same time, and whether your notebooks are using autoscale or fixed Spark settings. This makes it easier to understand whether the background CU is coming from parallel pipeline runs, Spark sessions that stayed alive, or carry‑forward from previous workloads.
What you’re seeing is probably not background activity that is still running.
Fabric smooths the CU consumption of background operations over 24 hours. So a pipeline or notebook that finished 12 hours ago can still show up as contributing to your current background usage. There is nothing to “clear” in that case. It is accounting for compute that was already consumed.
That also explains why scaling down from F64/F62-ish capacity to F32 can hurt much more than the Spark job view suggested. Looking only at the peak CUs used by Spark doesn’t give you the full capacity picture. You also have the pipelines, copy activities, notebooks and other operations contributing to the 24-hour smoothed usage.
I’d use the Capacity Metrics app to identify which operations are contributing most over that 24-hour window, and optimize those rather than trying to remove old background jobs.
The 15-minute orchestrator would be the first thing I’d look at. Pulling from 42 sources every 15 minutes is a lot of activity. I’d question whether all 42 sources actually need that frequency, whether you can process incrementally, and whether some parts of the pipeline can run less often.
In other words, I wouldn’t size the capacity based on the maximum Spark CUs you see during a job. I’d size it based on the total workload over time, including the smoothed background consumption.
The Capacity Metrics app is much more useful for that than the Spark job view alone.
