You create an EC2 CPU alarm, but it shows INSUFFICIENT_DATA and no email arrives. That state alone does not prove that configuration failed. Check, in order, whether the metric has data, whether the evaluation condition was met, and whether notification delivery is ready.
What does INSUFFICIENT_DATA mean for a CloudWatch alarm?
An alarm evaluates metric values collected over time, such as CPUUtilization. A newly created alarm may show INSUFFICIENT_DATA before it has enough data to evaluate. This is neither a CPU reading of 0% nor proof that the server is healthy. CloudWatch's missing-data treatment also affects how absent points influence the state.
Suppose you watch one EC2 instance's average CPU usage in five-minute periods with a condition of greater than 80%. These values are illustrative, not live measurements:
| Evaluation point | Five-minute average CPU | > 80% | Interpretation |
|---|---|---|---|
| No value yet | — | Cannot evaluate | Insufficient data |
| First observation | 18% | False | On the OK side |
| After load increases | 86% | True | On the alarm side |
Actual state transitions depend on the configured evaluation periods, required data points, and missing-data treatment. One row does not guarantee an immediate transition for every alarm.
The diagram separates missing metric data from a value crossing the threshold. Its 18% and 86% are examples; actual alarm state follows the evaluation configuration.
Where should you look if the alarm does not move?
First confirm that the alarm watches CPUUtilization for the intended EC2 instance. A similar instance name or incorrect dimension can point you at a different graph. Then inspect the statistic, period, and threshold. > 80 excludes exactly 80.
If the graph has values but the alarm does not change when expected, inspect the evaluation conditions. Was only one point high, or were enough evaluation periods met? The alarm's state history can help distinguish missing values from observed values that did not satisfy the condition.
Why might email not arrive after an alarm transition?
Alarm state and message delivery are separate stages. Check that the alarm action targets the intended SNS topic and that the email subscription is confirmed, not pending confirmation. Follow alarm state → alarm action → SNS subscription rather than refreshing the inbox alone.
Generating CPU load can test an alarm, but running such a test casually on a production instance may slow real requests. Outside an isolated lab, inspect configuration and observed values first, then scope any load test. A CPU alarm also does not explain the root cause of an incident by itself; if CPU is high, inspect the application and user impact separately.
Key takeaways
INSUFFICIENT_DATA is not an OK verdict. Check the target metric, statistic and evaluation settings, state-change reason, and SNS subscription in sequence. Treat alarm transitions and notification delivery as distinct steps.
