4.1.2. Monitoring Data Ingestion and Transformation

💡 First Principle: Different Fabric items have different monitoring approaches. Understanding where to look for each item type speeds up troubleshooting.

Monitoring by Item Type

Semantic model refresh: schedule it in the semantic model's settings under Scheduled refresh (up to 48 refreshes a day on a Fabric or Premium capacity) and keep Send refresh failure notifications on, adding extra contacts if needed. No pipeline is required. Selecting a refresh in Monitor hub (or in refresh history) opens its refresh detail page: start and end times, capacity, gateway, each attempt, and the error details. Each attempt's Execution details link shows its execution metrics, the place to start when a refresh is slow; semantic model operation logs in workspace monitoring (4.1.4) break a refresh into its processing steps. A "data source credentials" error on a Direct Lake model points to the cloud connection configured in the model's settings (SSO or a fixed identity to the lakehouse), not to an on-premises gateway.

Capacity monitoring with the Microsoft Fabric Capacity Metrics app: Monitor hub tells you whether runs succeeded; the Capacity Metrics app tells you what they cost. It shows CU consumption by workspace, item and operation over time, plus throttling and overload events. Open it when a capacity nears its limit or one workspace dominates usage (often background refreshes and pipeline runs nobody is watching). Reading it:

• Smoothed, not instantaneous: bursts are spread over future time (interactive operations over minutes, background operations over 24 hours), so a short spike isn't punished but sustained overuse is. Bursting costs nothing extra.
• Smoothed CU above 100% means the capacity is using future capacity; the first 10 minutes of it are overage protection, and anything beyond becomes carryforward. Idle capacity burns the debt down; throttling begins only once the debt passes the thresholds in 2.1.2, escalating from delaying new interactive jobs, to rejecting new interactive jobs, to rejecting background jobs too. Running operations are never killed; only new requests are delayed or rejected.
• Smoothed CU% that stays high around the clock (say 85 to 95%) means the SKU is undersized for the workload: scale up or move workloads to another capacity. A spike confined to one window points to a burst of concurrent work in that window, such as refreshes and pipeline runs all scheduled for the same time.
• Pausing a capacity bills the accumulated carryforward at once; it doesn't make the debt free.
• Idle import semantic models can be evicted from capacity memory. The first queries afterwards reload them, so reports stay slow until the models are warm again.