Find expensive queries from Capacity Metrics (Generally Available)

When warehouse capacity usage spikes, you need to quickly understand what ran, which warehouse drove the usage, and which queries require investigation. 

The Monitor in warehouse action in the Microsoft Fabric Capacity Metrics app connects the capacity-level view directly to Warehouse Monitor. It opens the selected warehouse with the relevant time window already applied, eliminating manual correlation across monitoring experiences. 

Figure: Animated GIF - demonstrating how to navigate from a Capacity Metrics timepoint to Warehouse Monitor in four steps.

Follow the activity into your warehouse 

1. Open Capacity Metrics: From the Compute page, select your capacity and review CU % over time. Capacity Units, or CUs, represent the compute consumption tracked for the capacity.
2. Choose a timepoint: Select the usage increase you want to investigate, and then select Explore and open TimePoint Detail.
3. Choose an operation window: Under Background operations for time range, select a supported warehouse query operation whose Start and End times cover the interval. Then select Monitor in warehouse.
4. Explore Warehouse Monitor: Open Query history to review statements that ran during the selected interval. 

Access required: Access to the Capacity Metrics app and the Admin role in the workspace containing the warehouse. For supported operations and navigation, refer to the Monitor in warehouse documentation.

Find the queries worth investigating 

Start with CPU time. Add the column through Column options and sort from highest to lowest. CPU time is the processor time allocated to an execution. It is not elapsed duration or the Capacity Units billed for an individual query. 

No single metric explains the complete workload. Review these columns together: 

• Data scanned: Identify statements that read large volumes of data. Compare OneLake reads with local disk, and memory reads to understand caching behavior. 
• Result cache hit: A value of 2 means the query reused a cached result, 1 means the execution created a result set cache, and 0 means result caching did not apply. 
• Query text: Review joins, predicates, and filters for unnecessary scans or processing. 
• Label: Connect statements to a workload, business process, or test variation. 
• Is distributed: Separate distributed executions, represented by 1, from nondistributed requests, represented by 0. 

For queries with high CPU time or data scanned, select View similar runs to determine whether the behavior is recurring or isolated. Add Query Insights fields such as application, SQL pool, status, and error code to identify the originating workload and distinguish expensive successful executions from failed or interrupted ones. 

For field definitions, refer to the query execution history column reference documentation.

Make the same correlation with AI 

The Data Warehouse operations skill in Skills for Fabric can correlate Capacity Metrics data with Query Insights activity for the same warehouse and time window, using your existing permissions. 

Example prompt: 

Investigate the capacity spike for my warehouse from 14:00 to 15:00 UTC on November 3, 2026. Identify queries with high CPU time or data scanned, explain why each query stands out, and suggest the next investigation step. 

Review the supporting metrics and query details before making tuning or workload-management decisions. 

Next steps 

Try Monitor in warehouse the next time you see a capacity usage increase. Start with CPU time and data scanned, compare similar runs, and use workload metadata to determine what drove the activity. 

For more guidance, refer to the Warehouse performance guidelines, query blocking troubleshooting, and Monitor T-SQL queries documentation.