Fabric capacity alerts arrive after users complain: monitor the risk window

A platform owner learns about throttling from a report user, then opens Capacity Metrics to reconstruct the incident. A current Fabric community question asks how to catch pressure earlier. One utilization number is not enough: Fabric smooths usage, and a brief spike can differ materially from an impending rejection.

Watch the state that affects people

Microsoft documents progressive throttling: interactive delay, interactive rejection and eventually background rejection as future capacity is consumed. Monitor those states alongside utilization and capacity overage. A threshold alert is a prompt to investigate, not a guarantee that a request will be rejected or that spend is capped.

Use the right time window

The Capacity Metrics preview guidance separates Latest, Last 1 hour and longer historical views. Its latest values can lag roughly 10–15 minutes, so define the alert-to-investigation expectation accordingly. Use the health view to find at-risk capacities; drill into the compute page and item details to identify operations, owners and the affected workspace. Record the user-visible start time separately from the metrics ingestion time.

Give the alert an owner and action

For each important capacity, document who receives the alert, what metric or stage fired, which workloads can be deferred, and when the team escalates or changes capacity. Test the runbook during a known load window. Repeatedly increasing the SKU without finding the expensive operation turns an incident response into a cost habit.

Adovo’s view

Monitoring earns its place when it changes the decision before the customer notices. The useful alert names the risk, the responsible workload and the next action. A dashboard viewed only after a complaint is a history book.