Forum Discussion
CapacityLimitExceeded + NoCapacitiesInRegion after stuck system session — 24hr outage on F64 France
Hi community,
We are experiencing a 24+ hour production outage on our F64 Fabric capacity
(France Central) and need urgent help.
**What happened:**
1. On March 15 ~07:10 UTC a system session (session 138) got stuck waiting
on XE_LIVE_TARGET_TVF and ran unattended for 55 hours. Fabric never
cleaned it up automatically.
2. On March 17 ~13:21 UTC, 43 additional concurrent sessions appeared
simultaneously (same 8 query hashes), all stuck on EDC_EXEC wait type,
causing a CU fan-out and triggering throttling.
3. A system process then acquired a schema modification lock (LCK_M_SCH_M)
and never released it — blocking all subsequent sessions. Could not be
killed (system process).
5. After eventually suspending/resuming at ~17:00 UTC March 17, we are now
getting the following errors:
- NoCapacitiesInRegion
- CapacityLimitExceeded (interactive operations rejected, background works)
- All pipelines and Power BI visuals failing
- SQL queries against the Warehouse still work
we guess this is happening because we ran out of capacity
**Current status:**
Warehouse SQL works but all interactive operations (pipelines, visuals) are
still throttled 24hrs later. Waiting for 24hr smoothing window to burn down.
**Questions:**
1. Is XE_LIVE_TARGET_TVF wait type on a system session a known platform bug?
2. Should Fabric automatically terminate sessions stuck for 55+ hours?
3. Why did capacity pause fail via both portal and API during the incident?
4. Any way to force-reset the interactive throttling budget without
waiting for the full 24hr smoothing window?
I am still trying to get more information but cannot access to the DW that had problems due to no capacity error.
Activity ID: 8aa6a102-b26a-469a-9e14-e82e9113281e
Error time: 2026-03-18 06:35 UTC
Capacity: F64, France Central
Thanks,
Best regards,
4 Replies
Sorry to hear that, can you check rapidely on utilization if you exceed 100% here :
There is currently no "reset button" for the 24-hour smoothing window. It's based on a burst and smoothing system on the capacity, so If you consumed 500% of your capacity in one hour, that debt must be "paid back" over the following 24 hours (smoothing).
You can also use Surge Protections to limit the usage of background operations and have at least a minimum of capacity for Interactive Operations.
For the rest of your questions, I don't have all answers but a best practices on Production is to have separate capacities : if you identify 2 or 3 specific items (reports, notebooks or warehouse) that are using a lot of CU, consider a mutli-capacity architecture. Instead of running everything on a single F64, you can provide a smaller, secondary capacity for the data processing parts : data ingestion (pipelines, dataflow gen2...), spark notebook... So you can have your Production Warehouse and reporting on the F64 remain responsive and unaffected.
Hope it can help you !
Best regards,
Antoine
Hi Freighar ,
We’d like to follow up regarding the recent concern. Kindly confirm whether the issue has been resolved, or if the issue is not resolved yet, we recommend raising a Microsoft Fabric support ticket with the relevant details workspace, lakehouse, timestamps, and reproduction steps so this can be investigated further by the product team and addressed appropriately.
Please refer below link on how to raise a contact support or support ticket.
How to create a Fabric and Power BI Support ticket - Power BI | Microsoft Learn
Regards,
Community Support Team.Hi Freighar ,
Could you please confirm if you’ve already raised the support ticket? If not, please go ahead and create one.
Also, once you get any update from the support team, kindly share it here it will be helpful for others facing the same issue.Thank you.
