Trying Out the New CloudWatch Alarms Feature: "Warm-up Period"
This page has been translated by machine translation. View original
Introduction
On September 1, 2026, AWS announced in What's New that Amazon CloudWatch alarms now support a warm-up period.
According to What's New, the feature is available in all Regions where Amazon CloudWatch is offered, and there is no additional charge beyond standard CloudWatch alarm pricing.
What is the warm-up period?
The warm-up period is a grace period that delays the start of evaluation immediately after an alarm is created, which suppresses false alarms caused by metrics that have not yet arrived.
Previously, if you created an alarm while metrics had not yet arrived, CloudWatch evaluated its state from the first evaluation timing based on the treat missing data setting. In contrast, during the warm-up period the alarm's state (StateValue) is INSUFFICIENT_DATA. The evaluation state (EvaluationState) becomes IN_WARM_UP, and alarm actions are not executed.
The warm-up period can be specified in both PutMetricAlarm and PutLogAlarm. For the required field WarmUpPeriodDurationInMinutes, you specify 1 to 2,880 minutes (2 days). The default value of the optional field OnlyStartEvaluatingAfterWarmUpPeriodEnds is false. In this case, the warm-up ends early once the evaluation window (Period × Evaluation Periods) is filled. If you set it to true, evaluation does not start until the warm-up period expires, even if data arrives early. The documentation also states that Datapoints to Alarm does not affect the early-termination decision.
Note that warm-up is applied only once, at alarm creation.
Warm-up applies only once at alarm creation and does not restart.
What I tested
I ran the test with AWS CLI 2.36.36. This version of aws cloudwatch put-metric-alarm supports --warm-up-configuration.
Alarm configuration
Targeting custom metrics in the namespace WarmUpDemo/233910, I created four alarms at the same time in the ap-northeast-1 Region. The threshold and evaluation periods are common to all four alarms.
--statistic Average --period 60 --evaluation-periods 1 --datapoints-to-alarm 1
--threshold 80 --comparison-operator GreaterThanThreshold
--treat-missing-data breaching
I chose breaching for handling missing data because with the default, missing, the alarm simply stays in INSUFFICIENT_DATA when data is missing, so there would be no behavioral difference with or without warm-up.
For the warm-up setting (--warm-up-configuration), I used three patterns (none, 5 minutes, 5 minutes + full wait), and created four alarms by combining them with the target metrics.
A: warmup-demo-A-nowarmup metric=m1 指定なし
B: warmup-demo-B-warm5 metric=m1 {"WarmUpPeriodDurationInMinutes":5}
C: warmup-demo-C-warm5 metric=m2 {"WarmUpPeriodDurationInMinutes":5}
D: warmup-demo-D-warm5-full metric=m2 {"WarmUpPeriodDurationInMinutes":5,"OnlyStartEvaluatingAfterWarmUpPeriodEnds":true}
With the alarm creation time as t=0, metrics were sent at 20-second intervals starting at t+120 seconds and stopped at t+780 seconds. Nothing was sent until t+120 seconds. From t+120 seconds onward, m1 kept receiving the value 10, which is below the threshold. For m2, I sent the value 95, which exceeds the threshold, between t+120 and t+240 seconds, and returned the value to 10 from t+240 seconds onward.
You can check the settings of the four alarms with describe-alarms.
aws cloudwatch describe-alarms --alarm-name-prefix warmup-demo --query 'MetricAlarms[].{N:AlarmName,M:MetricName,W:WarmUpConfiguration}' --output json
[
{
"N": "warmup-demo-A-nowarmup",
"M": "m1",
"W": null
},
{
"N": "warmup-demo-B-warm5",
"M": "m1",
"W": {
"WarmUpPeriodDurationInMinutes": 5,
"OnlyStartEvaluatingAfterWarmUpPeriodEnds": false
}
},
{
"N": "warmup-demo-C-warm5",
"M": "m2",
"W": {
"WarmUpPeriodDurationInMinutes": 5,
"OnlyStartEvaluatingAfterWarmUpPeriodEnds": false
}
},
{
"N": "warmup-demo-D-warm5-full",
"M": "m2",
"W": {
"WarmUpPeriodDurationInMinutes": 5,
"OnlyStartEvaluatingAfterWarmUpPeriodEnds": true
}
}
]
N, M, and W in the output are short display names assigned in the query; the field names returned by the API are AlarmName, MetricName, and WarmUpConfiguration. Even for B and C, where I omitted the early-termination setting, false was explicitly shown. For A, which had no warm-up specified, WarmUpConfiguration itself was null.
State immediately after creation
I tracked the state by polling at 20-second intervals.
aws cloudwatch describe-alarms --alarm-name-prefix warmup-demo --query 'MetricAlarms[].[AlarmName,StateValue,EvaluationState]' --output text
The elapsed seconds is a column added at polling time. The remaining columns are, in order, the alarm name, StateValue, and EvaluationState. The following are the results from t+3 to 43 seconds.
t+3s warmup-demo-A-nowarmup INSUFFICIENT_DATA None
t+3s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+3s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+3s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+23s warmup-demo-A-nowarmup INSUFFICIENT_DATA None
t+23s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+23s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+23s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+43s warmup-demo-A-nowarmup ALARM None
t+43s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+43s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+43s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
The situation of missing metrics and the breaching setting are common to all four alarms. A, which has no warm-up specified, was still INSUFFICIENT_DATA at the t+23 second poll, but was ALARM at the next poll at t+43 seconds. At the same point, B / C / D were still in warm-up. The EvaluationState of A, which has no warm-up specified, is null, which is displayed as None in text output.
Early termination and full wait
When tracked at the same 20-second interval, B and C, which terminate early by default, had already started evaluation at the t+190 second poll. Only D, with the full wait, remained in warm-up.
t+169s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+169s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+169s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+190s warmup-demo-A-nowarmup ALARM None
t+190s warmup-demo-B-warm5 OK None
t+190s warmup-demo-C-warm5 ALARM None
t+190s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+232s warmup-demo-A-nowarmup OK None
t+232s warmup-demo-B-warm5 OK None
t+232s warmup-demo-C-warm5 ALARM None
t+232s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+317s warmup-demo-C-warm5 OK None
t+317s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+338s warmup-demo-A-nowarmup OK None
t+338s warmup-demo-B-warm5 OK None
t+338s warmup-demo-C-warm5 OK None
t+338s warmup-demo-D-warm5-full OK None
A, without warm-up, stayed in ALARM at the polls from t+43 seconds onward, and returned to OK at the t+232 second poll after data arrived. B, which terminates early by default, became OK at the t+190 second poll without passing through ALARM, without waiting for the 5 minutes to expire after data arrived. C has the same early-termination setting, but its target metric is m2, which contains a spike. Because evaluation started early, it detected the 95 sent during the warm-up period and went into ALARM.
D, with the full wait specified, was still in warm-up at t+317 seconds and became OK at the next poll, t+338 seconds. Evaluation started after the 5 minutes (300 seconds) expired. The value at that point had returned to 10, so it transitioned directly from INSUFFICIENT_DATA to OK and did not detect the spike.
You can also confirm this difference from the state transition history.
State transition history of the 4 alarms
aws cloudwatch describe-alarm-history --alarm-name <アラーム名> --history-item-type StateUpdate --query 'reverse(AlarmHistoryItems[].{T:Timestamp,S:HistorySummary})' --output json
T / S are also short display names; the field names returned by the API are Timestamp / HistorySummary.
--- warmup-demo-A-nowarmup ---
[
{
"T": "2026-09-01T23:39:52.933000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to ALARM"
},
{
"T": "2026-09-01T23:42:52.928000+09:00",
"S": "Alarm updated from ALARM to OK"
}
]
--- warmup-demo-B-warm5 ---
[
{
"T": "2026-09-01T23:42:16.303000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to OK. State now evaluated with the full set of metrics matching the query"
}
]
--- warmup-demo-C-warm5 ---
[
{
"T": "2026-09-01T23:42:15.880000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to ALARM. State now evaluated with the full set of metrics matching the query"
},
{
"T": "2026-09-01T23:44:15.879000+09:00",
"S": "Alarm updated from ALARM to OK"
}
]
--- warmup-demo-D-warm5-full ---
[
{
"T": "2026-09-01T23:44:28.840000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to OK. State now evaluated with the full set of metrics matching the query"
}
]
D's history has no ALARM entries at all. As described in the previous section, this is because the value at the time evaluation started was 10. B also has no ALARM entries at all. B targets m1, and no data exceeding the threshold arrived after evaluation started. For both B and D, no StateUpdate history entries were added during the warm-up period, and the first entry was from the point when evaluation started. Since the alarm stays in INSUFFICIENT_DATA throughout warm-up, no state change that would be recorded in the history occurs. In this case, it is not abnormal for no state transitions to be recorded in the alarm history.
Behavior after sending stopped
I stopped sending metrics at t+780 seconds and checked the subsequent state with the same describe-alarms as before. +2min / +3min is the elapsed time since sending stopped.
--- +2min ---
warmup-demo-A-nowarmup OK None
warmup-demo-B-warm5 OK None
warmup-demo-C-warm5 OK None
warmup-demo-D-warm5-full OK None
--- +3min ---
warmup-demo-A-nowarmup ALARM None
warmup-demo-B-warm5 ALARM None
warmup-demo-C-warm5 ALARM None
warmup-demo-D-warm5-full ALARM None
At the poll about 3 minutes after sending stopped, all four alarms were in ALARM. EvaluationState remained null for all four alarms, and none of them returned to IN_WARM_UP up to this point. How missing data that occurs during operation is handled is, as before, determined by the treat missing data setting.
Summary
CloudWatch alarms now let you specify a grace period at creation. This lets you suppress false alarms caused by metrics that have not yet arrived right after creation, without changing the treat missing data setting. With OnlyStartEvaluatingAfterWarmUpPeriodEnds, you can choose whether to start evaluation as soon as data arrives or to wait until the period expires.
For example, in a setup where you launch EC2 with IaC and then deploy an application, metrics are missing until the application has started and can send custom metrics. Even for an alarm with treat missing data set to breaching, specifying a warm-up period at creation suppresses the transition to ALARM during this initialization.
This suits use cases where you want to give the start of CloudWatch alarm evaluation some leeway while waiting for an application to start. However, it is not a feature that replaces ELB target health checks or the Auto Scaling initialization grace period. Because warm-up is applied only once at creation, you still need to prepare for missing data during operation with the treat missing data setting.
References
