Fabric can now trace a capacity spike into warehouse queries—but correlation is not causation

Microsoft Fabric has made its Monitor in warehouse workflow generally available, connecting a Capacity Metrics timepoint to the relevant Warehouse Monitor window. For teams operating analytics agents and natural-language query workloads, the useful change is not another chatbot surface: it is a shorter evidence path from a capacity spike to the SQL statements, users and applications that overlapped it.

What the GA workflow actually does

An administrator can select a supported warehouse operation in Capacity Metrics and open Warehouse Monitor with the corresponding time range already applied. From there, Microsoft recommends inspecting CPU time, data scanned, result-cache status, query text, labels and whether execution was distributed. The launch post explicitly warns that CPU time is neither elapsed duration nor the Capacity Units billed to an individual query.

That distinction matters during an incident. Capacity Metrics ranks operations by compute impact in Capacity Units, while Query Insights reports warehouse execution details. A high-CU interval and a high-CPU query can overlap without proving that one metric can be converted into the other.

The AI skill has a deliberately narrow contract

Microsoft also documents a Data Warehouse operations skill for Fabric that can correlate Capacity Metrics with Query Insights for the same warehouse and time window. It runs bounded, read-only diagnostics under the operator’s existing Fabric permissions and returns a diagnosis, evidence, explanations it ruled out, recommendations and follow-up checks.

The skill can investigate failures, expensive query patterns, capacity spikes, pool pressure and possible cluster-key candidates. It does not perform lakehouse maintenance, configure SQL pools or implement cluster keys. Microsoft also says an overlap between a pressure interval and a request supports correlation rather than causation.

The identity boundary remains important: users need the required workspace role to read Query Insights and complete query text, while the GA Monitor workflow requires an admin role in the workspace containing the warehouse. The skill does not create a bypass around those permissions.

A safer incident runbook

Start with the Capacity Metrics timepoint and select an eligible warehouse operation. In Warehouse Monitor, rank statements by CPU time and data scanned, then compare similar runs and inspect application, status and error metadata. If the operations skill is used, require its answer to name the source views, supported time window and any missing data.

Do not let an agent turn the first correlation into a tuning change. Query Insights retains 30 days of history and can lag by up to 15 minutes; Capacity Metrics can expose fixed windows rather than arbitrary timestamps. Microsoft also cautions that a Capacity Metrics operation identifier is not the same as Query Insights’ distributed statement identifier, so the skill correlates the resolved warehouse and overlapping time range instead of joining those IDs.

The practical win is faster triage with a clearer audit trail. The safe boundary is equally clear: use the agent to collect and organize evidence, then keep pool changes, clustering decisions and workload-management actions behind human review and a separate change path.