Forum Discussion
Advocate IEventhouse Capacity Planner minimum CU not reflected in UI/API
Hi all,
We've set a minimum of 32 CU on our Eventhouse via Capacity Planner (autoscale alone isn't sufficient - we need guaranteed baseline capacity to protect a large bulk-ingestion workload from destination-side OutOfMemory during a migration). We've been told the 32 CU setting has been applied on the backend, but the Fabric UI and REST API (.show cluster / .show diagnostics) still report capacity/behavior consistent with a much lower tier.
Can anyone confirm:
Whether the a custom minimum CU value is actually enforced server-side even though the UI/API don't show it, and
When UI/API reporting is expected to catch up to reflect the configured minimum?
Any insight or similar experience would be appreciated.
Hi WorkFull22,
There are a couple of different surfaces involved here, so I wouldn't use the current REST value or .show diagnostics alone as proof that the 32 CU floor isn't being enforced.
The newer Eventhouse Capacity Planner supports 32 CU as a scheduled minimum. That minimum acts as a floor while autoscale remains enabled, and Microsoft notes that schedule changes can take up to 30 minutes to affect capacity.
One interesting wrinkle is that the current Eventhouse REST API still exposes minimumConsumptionUnits using the older minimum-consumption values rather than the newer Capacity Planner scheduler values. I therefore wouldn't assume that property currently represents the scheduled 32 CU floor. Similarly, .show diagnostics is documented mainly for observing things such as current hot-cache utilization, rather than retrieving the configured scheduler minimum.
For independent validation, I would check the Fabric Capacity Metrics app during a window where 32 CU is scheduled. Microsoft's Eventhouse consumption guidance says Eventhouse UpTime should accrue at least at the scheduled baseline during that window.
If the Capacity Planner UI itself still doesn't show 32 CU after the 30-minute propagation window, I would take that back to Microsoft Support with the Eventhouse ID, scheduled window and timestamps. I can't find a published SLA or roadmap date for REST/UI reporting parity with the newer scheduler, so Microsoft would need to confirm the backend state in that case.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
6 Replies
- ShivekMaharaj
Community Champion
Hi WorkFull22,
There are a couple of different surfaces involved here, so I wouldn't use the current REST value or .show diagnostics alone as proof that the 32 CU floor isn't being enforced.
The newer Eventhouse Capacity Planner supports 32 CU as a scheduled minimum. That minimum acts as a floor while autoscale remains enabled, and Microsoft notes that schedule changes can take up to 30 minutes to affect capacity.
One interesting wrinkle is that the current Eventhouse REST API still exposes minimumConsumptionUnits using the older minimum-consumption values rather than the newer Capacity Planner scheduler values. I therefore wouldn't assume that property currently represents the scheduled 32 CU floor. Similarly, .show diagnostics is documented mainly for observing things such as current hot-cache utilization, rather than retrieving the configured scheduler minimum.
For independent validation, I would check the Fabric Capacity Metrics app during a window where 32 CU is scheduled. Microsoft's Eventhouse consumption guidance says Eventhouse UpTime should accrue at least at the scheduled baseline during that window.
If the Capacity Planner UI itself still doesn't show 32 CU after the 30-minute propagation window, I would take that back to Microsoft Support with the Eventhouse ID, scheduled window and timestamps. I can't find a published SLA or roadmap date for REST/UI reporting parity with the newer scheduler, so Microsoft would need to confirm the backend state in that case.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
v-abhinavmuCommunity Support
Hi WorkFull22,
Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks ShivekMaharaj for sharing valuable insights.
Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.
Thank you for being part of the Microsoft Fabric Community.
- v-abhinavmu
Hi WorkFull22,
May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.
Thank you
- WorkFull22
Hi yes this is still an issue
- ShivekMaharaj
Hi WorkFull22,
Yes, I would keep this open.
The current documentation makes the distinction a little clearer now. The new Capacity Planner scheduler is still in Preview and uses the newer minimum CU tiers such as 2, 4, 8, 12, 16, 24, 32 and 48.
The Eventhouse REST API, however, still documents minimumConsumptionUnits using the older static values such as 2.25, 4.25, 8.5, 13, 18, 26, 34 and 50. So seeing 2.25 from that property does not necessarily mean the scheduled 32-CU floor has not been applied.
For validation, I would now check the scheduled window against Eventhouse UpTime in the Fabric Capacity Metrics app. Microsoft documents that when a scheduled minimum is active, UpTime should reflect at least that baseline for the duration of the window.
Also allow for the documented propagation delay. Capacity Planner changes can currently take up to 30 minutes to affect capacity while the feature is in Preview.
If the schedule shows 32 CU, the window has been active for more than 30 minutes, and the Capacity Metrics data still does not reflect that baseline, I think that would be useful evidence to take back to Microsoft Support.
I still cannot find a documented REST endpoint that exposes the new per-hour Capacity Planner schedule, or a published date for when the older reporting surfaces will reflect it.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
