Alarm tasks

Event-triggered tasks monitor resource metrics in real time and automatically execute scaling rules when an alert condition is met. Use event-triggered tasks when traffic spikes are unpredictable — they let your scaling group respond to actual load rather than a fixed schedule.

How it works

1. Auto Scaling continuously collects metric data from the resources in your scaling group (for example, CPU utilization or memory usage).

2. When the metric crosses the threshold you defined, an alarm is triggered.

3. Auto Scaling executes the scaling rule associated with the alarm task.

4. After execution, the scaling group enters a cooldown time to prevent rapid, repeated scaling.

Monitoring types

Auto Scaling supports two types of event-triggered tasks:

• System monitoring: Monitors built-in Cloud Monitor metrics for Elastic Compute Service (ECS) instances in the scaling group, such as CPU utilization, memory usage, system disk read/write IOPS, and network traffic. No additional instrumentation is required.

• Custom monitoring: Monitors metrics from your own monitoring system, integrated via Cloud Monitor custom metrics. Use this type when the built-in system metrics do not reflect your actual workload — for example, queue depth or request latency from your application layer.

Choose a scaling rule type

Each event-triggered task executes one scaling rule when the alarm fires. Auto Scaling supports three rule types:

Recommendation: Start with a target tracking scaling rule. It requires the least configuration and automatically compensates as your load changes. Use step scaling when you need precise control over adjustment size at different metric ranges.

Target tracking: metrics that do not work well

Target tracking works best when the selected metric changes proportionally as the number of instances changes. Avoid using the following metrics with target tracking:

• Load balancer request count: The total number of requests received by a Server Load Balancer (SLB) instance does not decrease as more instances are added — it increases because more capacity handles more requests.

• Request latency: Latency can increase under load but does not change proportionally when you add instances, making it unreliable as a target tracking metric.

For these metrics, use a step scaling rule or simple scaling rule instead.

Step scaling: how adjustments are calculated

A step scaling rule divides the metric range above or below the threshold into bands, and each band maps to a specific adjustment.

For example, if your CPU utilization threshold is 60% and your scaling group currently has 10 instances:

• CPU at 65% (5% above threshold): add 1 instance → 11 instances

• CPU at 75% (15% above threshold): add 3 instances → 13 instances

• CPU at 85% (25% above threshold): add 5 instances → 15 instances

The adjustment for each step is defined when you create the scaling rule. Decimal results are rounded down.

Prerequisites

Before you begin, ensure that you have:

• A scaling group in the Active state

• At least one scaling rule created in the scaling group

• (For custom monitoring) Custom metrics already reported to Cloud Monitor

Create an event-triggered task

Create a system monitoring task

1. Log on to the Auto Scaling console.

2. In the left-side navigation pane, choose Scaling Tasks > Event-Triggered Tasks.

3. In the top navigation bar, select the region where your scaling group is located.

4. Click the Event-triggered Tasks (System) tab, then click Create Event-triggered Task.

5. Configure the task parameters.

1. Click OK.

Create a custom monitoring task

Follow steps 1–3 above, then click the Event-triggered Tasks (Custom) tab and click Create Event-triggered Task. In addition to the parameters above, specify:

When multiple event-triggered tasks fire simultaneously

A scaling group can have multiple event-triggered tasks. When more than one alarm fires at the same time:

• Scale-out: If any scale-out alarm fires, a scale-out action is triggered.

• Scale-in: A scale-in action is triggered only when all scale-in alarms are met simultaneously.

Always configure event-triggered tasks in pairs — one for scale-out and one for scale-in — to ensure your scaling group can both expand and contract automatically.

Usage notes

• Cooldown time: After a scaling rule executes, the scaling group enters a cooldown time. No new scaling activity starts during this time. If an alarm fires during cooldown, Auto Scaling re-evaluates the alarm after the cooldown ends. Set the cooldown time on the scaling group or scaling rule based on how long your instances take to become healthy and start serving traffic.

• Effective period and cron expressions: Cron expressions use UTC+0. If your team works in UTC+8, subtract 8 hours from your target time window. For example, to restrict scaling to 09:00–18:00 Beijing time, set the cron expression to 1-10 .

• Alarm state vs. execution: An alarm can fire and put the task in the Alert state without executing the scaling rule — for example, when the alarm fires outside the effective period or when the scaling group is in cooldown.

• Target tracking tasks cannot be manually modified: If an event-triggered task uses a target tracking scaling rule, you cannot edit the task's basic settings after creation. Delete and recreate the task to change its configuration.

Best practices

Pair scale-out and scale-in tasks

Always create a matching scale-in task for every scale-out task. Without a scale-in task, your scaling group expands under load but never contracts, leaving idle instances running.

Use statistical period to filter noise

Short statistical periods (1 minute) detect spikes quickly but may trigger scaling for transient load bursts. For workloads with occasional CPU spikes that resolve within minutes, use a longer statistical period (5 minutes) and set Trigger After to 3 or more consecutive periods to confirm sustained load.

Set up failure notifications

Configure Cloud Monitor alert notifications so that you are notified if an event-triggered task fails to execute — for example, due to a scaling group in cooldown or at maximum capacity. Route notifications to email, SMS, or a webhook so your team can respond before load exceeds capacity.

Do not rely on event-triggered tasks alone for predictable peaks

Event-triggered tasks react to load that has already arrived. For traffic patterns you can predict in advance — such as a marketing campaign or a nightly batch job — add a scheduled task to pre-scale before the peak. Use event-triggered tasks alongside scheduled tasks for complete coverage.

What's next

• Create event-triggered tasks of the system monitoring type

• Create event-triggered tasks of the custom monitoring type

• Manage event-triggered tasks

• Scaling rules overview