FUAM capacity usage on Fabric – real-world experience?

[ucek]

Hi all,

I’m evaluating the Fabric Unified Admin Monitoring (FUAM) solution accelerator and I’m trying to understand its real impact on capacity usage before deploying it.

I’m currently running an F64 capacity and would like to avoid unexpected spikes or interference with production workloads.
From reviewing the repository and documentation, I understand that FUAM relies on pipelines, notebooks, and Lakehouse storage, but I couldn’t find any concrete guidance on:

• Typical CU consumption (average or peak)
• Impact during initial deployment vs. ongoing runs
• How usage scales with tenant size (number of workspaces, activity volume, etc.)
• Recommended scheduling approach to minimize impact

If anyone has implemented FUAM in a real environment, I’d really appreciate insights such as:

• % of capacity usage observed
• Whether it caused noticeable throttling or performance degradation
• Best practices for scheduling and optimization

Thanks in advance!

I have posted the question on GitHub discussion but not sure if it's popular therefore decided to post it here as well 

[vanessa_fvg]

we are using it and have been for a while.  I only run it 2 x day.  no issues with the pipelines as yet.   Its a great accelerator for the ingestion part.   

however the reporting / semantic modelling...

the semantic model it is not well modelled at all, and therefore not optimised, it sent my f64 capacity into almost throttling from adding a filter on one of the pages, which made me look more closely at the model.. as a long time data modeller.  i suggest building your own  model / reports from the data.

[KevinChant]

If you are looking to implement FUAM long-term then I strongly advise moving both FUAM and the accompanying Capacity Metrics app to their own capacity. Otherise, if there is an issue with your capacity you won't be able to access either FUAM or the capacity metrics app to see what the problems are.

Depending on the size of your estate you can start with a small(ish) capacity and scale upwards.

[v-nmadadi-msft]

Hi @ucek 

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

[v-nmadadi-msft]

Hi @ucek 

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

Thank you.

[cengizhanarslan]

FUAM runs pipelines, notebooks, and Lakehouse storage on your capacity. The actual CU consumption depends heavily on tenant size (number of workspaces, users, activity volume) and how frequently the pipelines are scheduled.

From experience on an F64 capacity, FUAM consumed roughly 10% of the total CU during pipeline runs. This includes both the initial deployment phase and ongoing scheduled refreshes.

[Vinodh247 · Accepted solution]

In real environments, FUAM is not “free” but it is also not heavy if you deploy it sensibly. On an F64, most teams report low single-digit baseline impact (typically ~2-5% of capacity over time), with short spikes during ingestion runs. The initial deployment or backfill is the only phase that can be noticeable, sometimes briefly touching -10-15% depending on how much historical activity you pull and how many workspaces you scan. After that, steady-state runs are predictable and lightweight.

Scaling is mostly linear with metadata volume, not raw data size. More workspaces, more pipelines, more activity logs will increase notebook execution time and CU consumption, but it does not explode unless you are running very high-frequency ingestion. The Lakehouse footprint is negligible compared to compute.

The main risk is not constant load but poorly scheduled bursts. If you run FUAM pipelines at the same time as heavy ETL or Spark jobs, you can see contention or mild throttling. The fix is simple: schedule FUAM during off-peak windows, reduce frequency (for example, every 30 to 60 minutes instead of near real-time), and avoid full scans after the initial load. Incremental ingestion and partition pruning in notebooks make a big difference.

Bottom line: on an F64, FUAM is safe if you treat it like a monitoring workload, not a real-time pipeline. Keep it incremental, stagger execution, and you will not see meaningful impact on production.