How Fabric capacity throttling affects Activator

Throttling occurs when you consume more capacity resources than you purchased. Prolonged overload results in degraded performance and gaps in event processing. The Fabric throttling policy explains Fabric capacity throttling, its stages, available mitigations, and best practices to prevent it.

Stages of capacity overload

Activator distinguishes between three stages of capacity overload and throttling.

1. Capacity overloads lasting between 10 and 60 minutes.
2. Capacity overloads lasting over 60 minutes and up to 24 hours.
3. Capacity overloads lasting over 24 hours.

The following table summarizes the effect on interactive UI operations and Activator rule evaluation at each stage.

Stage 1: Overloads lasting 10 to 60 minutes

At this stage of capacity overload, Activator introduces several delays to prevent further overload and ensure that background processing continues to operate at peak performance. These steps prioritize background processing over interactive UI usage and minimize business impact. Rule evaluation (your business logic) keeps running, while UI operations are delayed.

• Loading and displaying of data-aware graphs is delayed by 20 seconds.

• Auto-refreshing of graphs is disabled. You can restart auto-refresh by toggling Live auto-refresh on, or by manually reloading the browser page.

• Loading of data-aware dropdown lists (such as time range selectors) is delayed by 20 seconds.

• Sending of test alerts is delayed by 20 seconds.

• Running of interactive queries is delayed and a banner informs you that capacity is exceeded.

  

Stage 2: Overloads lasting over 60 minutes to 24 hours

At this stage, Activator takes a few more steps to prioritize background processing over interactive UI usage and minimize business impact. Rule evaluation continues normally. All interactive UI operations are rejected. The rejections include:

• Data-aware graphs aren't displayed.
• Data-aware dropdowns aren't displayed.
• Test alerts aren't sent.

Stage 3: Overloads lasting over 24 hours

At this stage, Activator rejects both interactive and background operations. Rule evaluation pauses. You're notified by email and Activator banners.

• System notifications are sent to item owners to inform them that Activator is pausing rule evaluation.

  

• Banners inform you about the exceeded capacity and rejected interactive and background operations.

Recover from overload situations

You can wait for Activator to recover on its own. Don't issue new rule requests while you wait. If the overload situation continues, the Fabric Capacity administrator can take several actions to recover from capacity overload.

• Upgrade the SKU of the Fabric capacity. A larger SKU has more idle capacity per timepoint, which burns down carryforward faster.

• Pause and resume the capacity. Pausing results in a billing event for accumulated future capacity usage. When the capacity resumes, it starts with zero future capacity usage and can accept new operations immediately.

• Configure capacity Autoscale (P SKU capacities only).

• Move lower priority or high-consumption workspaces out of the capacity.

• If Activator rule executions are causing the overload, consider stopping the rules and adjusting their conditions.

For more information, see The Fabric throttling policy.

Related content

• Activator capacity consumption, usage reporting, and billing
• Apply filters to reduce Activator rule costs
• The Fabric throttling policy