This time we’re going bigger than ever. Fabric, Power BI, SQL, AI and more. We're covering it all. You won't want to miss it.
Learn moreDid you hear? There's a new SQL AI Developer certification (DP-800). Start preparing now and be one of the first to get certified. Register now
Hello,
We received a report from a customer saying that their data pipeline processing time has tripled — from about 3 minutes to 22 minutes — starting from February 21st.
After investigation, we found a discrepancy: the Fabric capacity in the Azure resource group shows F16 after the update, but in the Fabric portal (Workspace Settings), it still shows F4.
For context, to optimize costs for this customer, we have set up a scaling schedule:
6:00 AM – 7:00 PM: F16
Remaining hours: F4
We believe the 22-minute processing time corresponds to the pipeline running on F4 instead of F16, meaning the capacity update may not have been applied correctly in the Fabric portal.
Has anyone encountered a similar issue? Any insights would be appreciated. Thank you!
Solved! Go to Solution.
Hello @nvmtrang
The Microsoft Fabric workspace UI doesn't dynamically reflect the capacity SKU in real-time. So, you may have scheduled a change (i.e. scaled it up to F16 SKU), but the workspace is still going to show the baseline SKU (i.e. original F4). This is how it is designed.
To double check whether SKU scaling-up worked, is to look at the Capacity Metrics app. If you look at CU usage, it would generally indicate a higher CU availability as compared to when SKU was at F4.
Your Activity Logs screenshot does indicate that the scaling-up has happened. The issue with data processing time could be related to something else, like a recent change in the pipeline?
Hi @nvmtrang , Thank you for reaching out to the Microsoft Community Forum.
The Azure Activity Log confirms the capacity update succeeded, so this does not appear to be a failed scale operation. I think the workspace is still bound to an F4 capacity or the pipeline executed outside your 6:00 AM–7:00 PM F16 window. In Fabric, the workspace reflects the capacity it is assigned to and scaling schedules do not retroactively change a running job’s compute tier.
A jump from 3 minutes to 22 minutes is consistent with the workload running on F4 instead of F16, especially if it’s compute bound. Verify if the workspace’s assigned Capacity ID matches the scaled Azure resource and confirm the exact pipeline start time against the scaling window.
Hi @nvmtrang , Hope you're doing okay! May we know if it worked for you, or are you still experiencing difficulties? Let us know — your feedback can really help others in the same situation.
Hi @nvmtrang , hope you are doing great. May we know if your issue is solved or if you are still experiencing difficulties. Please share the details as it will help the community, especially others with similar issues.
Hey @nvmtrang,
Your screenshots helped us rule out:
I would suggest to check capacity name. Maybe the workspace is not attached to the capacity you are scaling. Then try manual scale to F16 and wait 10-15 min. If still F4, pause and resume capacity.
If you exhaust all options, I would recommend to raise a support ticket.
Please do share whatever works for you eventually, so that it helps us all in such scenarios.
Hi @nvmtrang , Thank you for reaching out to the Microsoft Community Forum.
The Azure Activity Log confirms the capacity update succeeded, so this does not appear to be a failed scale operation. I think the workspace is still bound to an F4 capacity or the pipeline executed outside your 6:00 AM–7:00 PM F16 window. In Fabric, the workspace reflects the capacity it is assigned to and scaling schedules do not retroactively change a running job’s compute tier.
A jump from 3 minutes to 22 minutes is consistent with the workload running on F4 instead of F16, especially if it’s compute bound. Verify if the workspace’s assigned Capacity ID matches the scaled Azure resource and confirm the exact pipeline start time against the scaling window.
Hello @nvmtrang
The Microsoft Fabric workspace UI doesn't dynamically reflect the capacity SKU in real-time. So, you may have scheduled a change (i.e. scaled it up to F16 SKU), but the workspace is still going to show the baseline SKU (i.e. original F4). This is how it is designed.
To double check whether SKU scaling-up worked, is to look at the Capacity Metrics app. If you look at CU usage, it would generally indicate a higher CU availability as compared to when SKU was at F4.
Your Activity Logs screenshot does indicate that the scaling-up has happened. The issue with data processing time could be related to something else, like a recent change in the pipeline?
Check out the April 2026 Fabric update to learn about new features.
Sign up to receive a private message when registration opens and key events begin.
| User | Count |
|---|---|
| 15 | |
| 11 | |
| 6 | |
| 6 | |
| 5 |