Discrepancy in CU Consumption Between Fabric Capacity Metrics and Fabric Chargeback Reporting

[MorelG]

Hello,
I’ve encountered a discrepancy in the reported Capacity Unit (CU) consumption between two official Microsoft reports: Fabric Capacity Metrics and Fabric Chargeback Reporting.

In both reports, I apply only a basic filter for a full day — specifically looking at data from 7 days ago. Since I’m working with historical data, I assume that delayed refreshes or similar timing issues should not be a factor. There are no additional filters or data limitations applied, yet the Sum of CU values differ between the two reports.

Has anyone else noticed this difference?What could be the reason behind such a discrepancy? Which of the two reports is considered more accurate or reliable for tracking CU usage?

Thank you in advance for any insights or experiences you can share.

[Anonymous · Accepted solution]

Hi @MorelG ,
Thank you for the prompt response @GilbertQ and  @lbendlin !
As per my investigation,the Capacity Metrics app gives the most detailed view of CU usage for monitoring and troubleshooting, while the Chargeback app is meant for daily cost tracking by workspace or user. Differences in totals are expected due to how data is aggregated (real-time vs daily) and some known telemetry issues. For the most accurate insights, use Capacity Metrics for operations and Chargeback for billing, and check Timepoint Details  in Capacity Metrics for deeper analysis.Refer the link here:
 https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app
https://learn.microsoft.com/en-us/fabric/enterprise/chargeback-app 

Hope this helps.
Thank you.

Regards,
Pallavi.

[GilbertQ]

Hi @MorelG 

It is rather odd that there's a discrepancy between the two reports. From my experience, I would rely on the Fabric Capacity Metrics app as being the source of truth.

[lbendlin]

Oh, we see the issues with that app every single day. Did you know they have a 100K operations limit per 30 second timeslot? Guess what, our capacities easily exceed that, resulting in us flying blind for x percent of our operations.  And don't get me started on the latency and batching issues.