Forum Discussion
CDSA Usage Keeps Rising After Pausing All Triggers – No Burndown, No Response
Hi TayRob16,
Thank you for reaching out to the Microsoft Fabric Community Forum. Also, thanks to tayloramy, for those inputs on this thread.
I understand that seeing CDSA usage continue to increase significantly, even after pausing triggers, can be quite concerning. It is important to note that pausing triggers only prevents new trigger activity it does not affect jobs that were already running, queued, or being retried by other services such as Power Automate, Logic Apps, or service principals. These jobs may continue to consume capacity in the background.Fabric applies smoothing over a 24-hour window for background workloads. This means you won’t see immediate burndown usage can look “stuck” at 0% even when triggers are paused, because those jobs are still being accounted for gradually.
Open the Capacity Metrics app → Timepoint view to spot which operations and workspaces are consuming the most. https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app
Cancel any active pipeline runs in the monitor. If the UI will not let you, you can use the pipelineRuns/cancel API. https://learn.microsoft.com/en-in/rest/api/datafactory/pipeline-runs/cancel?view=rest-datafactory-2018-06-01&tabs=HTTP
Turn off all other entry points that can re-enqueue work things like scheduled semantic model refreshes or external retry loops in Power Automate/Logic Apps.
https://learn.microsoft.com/en-in/power-bi/connect-data/refresh-dataAvoid using “pause capacity” to flush usage, pausing actually sums up all smoothed/overage usage immediately, which can make the spike look worse in your bill.
1. https://learn.microsoft.com/en-us/fabric/enterprise/pause-resume
2. https://learn.microsoft.com/en-us/fabric/enterprise/monitor-paused-capacitySince you have already logged a support ticket, I would suggest updating it with:
• Screenshots or exports from the Metrics app (top operations).
• Run IDs and UTC timestamps for any cancelled jobs.
That information will help the support team quickly identify and clear any runaway background workloads.Hope this helps clarify things and let me know what you find after giving these steps a try happy to help you investigate this further.
Thank you for using the Microsoft Fabric Community Forum.
Thank you so much for your response.
After two hours without acknowledgment, I was informed that my original ticket had been submitted through the wrong portal. I re-submitted the request via Power BI and received immediate assistance. However, the first recommendation was to pause the capacity—without investigating the background workloads I had flagged.
Their proposed root cause was a network connection issue with the data source. But in this case, the data source was Fabric itself—a Lakehouse—so the explanation didn’t hold. I also pointed out that my semantic models were not refreshing and that retry attempts were occurring every ten seconds for approximately ten minutes. Despite this, the support team was adamant that the retry loop and refresh failures had no connection to the capacity spike. Their focus remained on recommending a capacity upgrade, which wasn’t aligned with the nature of the issue.
Ultimately, I accepted their proposed solution because it felt like the only path forward, though I still don’t have clarity on what triggered the spike. The capacity has remained paused since yesterday, and I’m preparing to resume it and run a pipeline—hoping for stability.
I’ve documented the incident thoroughly, including screenshots showing my initial request for help, the burndown percentage remaining at 0%, and the CDSA usage rapidly increasing. Would these materials be helpful in keeping my billing neutral for the affected period?
If you have any guidance on how to approach this next step or better isolate the root cause, I’d be incredibly grateful.
Community SupportHi TayRob16,
Thank you for the follow-up question.
Thank you for sharing these details and for documenting the incident so thoroughly. I understand how frustrating it must have been to receive recommendations that didn’t directly address the workloads you had flagged.
On the technical side, the retry loop you observed (every 10 seconds for ~10 minutes) can itself create significant background load, which may explain the capacity spike you saw. To better isolate this, I recommend resuming capacity and re-running your pipeline while monitoring background workloads, refresh behaviour, and CDSA usage. If the spike recurs, please capture correlation IDs and timestamps so we can escalate to engineering for a deeper investigation.
I will also check internally whether additional diagnostics can be applied for Fabric Lakehouse refresh scenarios, since a network explanation would not apply in this case.
Hope this clears it up. Let us know if you have any doubts regarding this. We will be happy to help.
Thank you for using the Microsoft Fabric Community Forum.
Thank you for your response!
In the future if this happens, how do I contact someone to escalate it to the engineering team? I asked several times, they kept adding more people, but none of them were on the engineering team and we were only screen sharing.- tayloramy
Super User
Hi TayRob16,
You would need to open a support ticket and work with the support team. If you continue to have problems, and your org has a CSAM (Customer Success Account Manager), esclate through your CSAM.
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, please mark this as the solution.
