CloudWatch Alarm Stuck in INSUFFICIENT_DATA: Why It Stays Gray, the 1-Minute EC2 Period Trap, TreatMissingData (missing, notBreaching, breaching, ignore), Agent Metrics and the New Warm-Up Period

A CloudWatch alarm stuck in INSUFFICIENT_DATA means CloudWatch cannot currently determine the alarm's state from the available metric data, or the alarm has not started evaluating yet. It is not automatically an AWS service error. The metric might be reporting too infrequently, using the wrong namespace or dimensions, publishing only when an event occurs, or not reporting at all. Here is the counterintuitive part: changing missing data to "not breaching" can turn a permanently silent alarm green without fixing a single missing metric. The reliable fix is to determine why the data is absent, then choose a missing-data policy that matches what silence actually means for that metric.

aws cloudwatch describe-alarms \
  --alarm-names "High-CPU-Alarm"

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-10-17T09:00:00Z \
  --end-time 2026-10-17T10:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Jake owns a small mobile phone repair shop. His online booking website runs on an EC2 instance, and he created a CloudWatch alarm to notify him when CPU usage exceeds 80%. He expected a simple safety net: if his booking website becomes overloaded, his phone should receive a warning before customers start complaining.

Instead, the alarm stays gray and displays INSUFFICIENT_DATA. His website still works, but he has no reliable CPU warning. He considers changing the threshold from 80% to 50%, believing CloudWatch has not seen enough CPU activity to trigger it.

That threshold change would not solve the actual problem. A CPU reading of 20% is valid data that should result in OK; an absent CPU reading is missing data. The alarm's threshold answers whether the measured value is unhealthy, while the metric configuration determines whether CloudWatch has a measured value at all.

Understand what INSUFFICIENT_DATA actually means

When you open a CloudWatch alarm, you see one of three main states: OK, ALARM, or INSUFFICIENT_DATA. An OK state means the evaluated condition is within the configured threshold. An ALARM state means the evaluated condition breaches the alarm rule. INSUFFICIENT_DATA means the alarm cannot yet make the required determination or is waiting to begin evaluation.

A metric is a time series of measurements, such as CPU utilization, request count, error count, or available disk space. A data point is a recorded value associated with a timestamp. CloudWatch evaluates these values over configured periods to determine whether an alarm should change state.

For example, an alarm might evaluate three five-minute periods and require all three to exceed an 80% CPU threshold. Its evaluation periods setting is three, and its datapoints-to-alarm setting is also three. This arrangement is commonly described as a three-out-of-three alarm.

CloudWatch may retrieve additional older data points as part of its evaluation range, rather than looking at only the exact number of configured periods. This can help it evaluate an alarm when some recent points are missing. Consequently, one absent period does not automatically mean an alarm must enter INSUFFICIENT_DATA.

An alarm also initially enters INSUFFICIENT_DATA when it is created, before its first evaluation. That short initial state may resolve naturally as CloudWatch receives the necessary data. A persistent state requires you to examine the metric and configuration instead of assuming that creating the alarm failed.

Jake: "My website is running. Why does the alarm say it doesn't have enough information?"

Ethan: "The alarm isn't measuring whether your shop is open. It's evaluating a particular metric. We need to find out whether the readings for that metric are actually arriving."

Identify the cause before changing missing-data treatment

If your alarm remains gray, the fastest troubleshooting method is to separate configuration problems from publishing problems. First determine whether the expected metric has recent data. Then inspect whether the alarm is requesting the correct metric identity, statistic, unit, and time interval.

Many apparent CloudWatch outages are actually metric selection mistakes. Two metrics can share the same name but have different dimensions, namespaces, or units. They are not interchangeable merely because their names look identical in the console.

A blank metric graph helps identify where to investigate, but it does not establish which of these causes applies. A wrong Region can produce the same apparent absence as a stopped agent. Likewise, a custom metric reporting once an hour will look empty over many one-minute evaluation intervals.

Your first useful CLI operation is describe-alarms, which reveals what CloudWatch believes the alarm is monitoring. Your second is get-metric-statistics, which retrieves actual data points for the specific metric identity. Comparing those outputs avoids changing settings based on guesses.

Find the actual missing metric in the CloudWatch console

When your alarm remains in INSUFFICIENT_DATA, start from the alarm rather than searching blindly through all your metrics. The alarm details show the configured condition and monitored metric. You can then compare this configuration with the time series your resource actually publishes.

1. Open the AWS CloudWatch console and confirm the selected Region.
2. Choose Alarms and then All alarms.
3. Select the alarm showing INSUFFICIENT_DATA.
4. Review its state reason, graph, metric name, namespace, dimensions, period, and statistic.
5. Choose Edit to review the configuration.
6. Open Metrics and compare the metric series with the one selected by the alarm.
7. Inspect recent data points at the period used by the alarm before saving any changes.

A namespace groups related metrics, such as AWS/EC2 for EC2 service metrics. A dimension is a name-and-value identifier that distinguishes one time series from another, such as InstanceId=i-0123456789abcdef0. Both must match the publisher's metric definition.

Pay attention to the selected statistic, too. Average, Maximum, Minimum, Sum, and SampleCount answer different questions about a metric during a period. Choosing Sum for an event count may be sensible, while Average is commonly suitable for EC2 CPU utilization.

Inspect the alarm's state reason rather than relying only on its gray icon. A new alarm may be waiting for measurements, while a warm-up alarm may explicitly be waiting to start evaluation. A metric math expression may also produce missing results even when some of its underlying metrics exist.

If the console graph shows the expected metric but the alarm stays gray, note the graph's period, time range, statistic, and dimensions. A graph can aggregate data differently from the alarm. Matching those settings makes the comparison meaningful.

Use get-metric-statistics to prove whether data points exist

If the CloudWatch graph is unclear, retrieve the metric directly with the AWS CLI. The get-metric-statistics command requests measurements for a precise metric identity and time range. It tells you whether data exists for the namespace, metric name, dimensions, period, and statistic you specified.

First retrieve the alarm definition, using its name and the correct AWS Region. You can inspect the state reason, missing-data setting, evaluation periods, and dimensions. This establishes what the alarm expects before you make a separate statistics request.

aws cloudwatch describe-alarms \
  --alarm-names High-CPU-Alarm \
  --region us-east-1 \
  --query "MetricAlarms[].{
    Name:AlarmName,
    State:StateValue,
    Reason:StateReason,
    Namespace:Namespace,
    Metric:MetricName,
    Dimensions:Dimensions,
    Period:Period,
    Statistic:Statistic,
    EvaluationPeriods:EvaluationPeriods,
    DatapointsToAlarm:DatapointsToAlarm,
    MissingData:TreatMissingData
  }"

Replace the example instance ID and timestamps in the next command with your actual resource and recent UTC interval. The date range is an illustrative query window, not a live measurement from your account. For normal EC2 CPU monitoring, a 300-second period is an appropriate starting point when basic monitoring is enabled.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-10-17T08:00:00Z \
  --end-time 2026-10-17T10:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

The response contains a Datapoints array and the requested metric label. A populated array shows the returned measurements and their timestamps. An empty array means that the specified query did not return measurements, not necessarily that CloudWatch has lost every metric for the resource.

When the result is empty, change one diagnostic dimension at a time. Confirm the Region, then the namespace and dimensions, followed by the interval, statistic, unit, and period. This approach makes it easier to identify the actual mismatch instead of altering several settings and losing track of what changed.

Jake: "The dashboard has a CPU graph. Doesn't that prove the alarm should work?"

Ethan: "Only if the graph and alarm refer to the same metric, dimensions, period, and statistic. The CLI lets you compare the exact readings instead of trusting two similar-looking graphs."

Correct the namespace, dimensions, and unit that identify your metric

If CloudWatch returns no data even though the application publishes metrics, compare the publisher's metric identity with the alarm. Metrics are identified by their namespace, metric name, and dimensions. The unit also affects how statistics are selected and aggregated.

An EC2 alarm monitoring CPUUtilization ordinarily uses the AWS/EC2 namespace and the relevant instance dimension. If your application creates a custom metric named CPUUtilization under MyApplication, that is a different metric. An alarm configured for one does not automatically find readings from the other.

Dimensions are equally important. Suppose you terminated an instance and launched its replacement, then retained an alarm referencing the old instance ID. The replacement's CPU readings will not appear under the old ID. The alarm must be updated or managed through an approach that follows the correct replacement resource.

For custom metrics, dimensions might include Environment=production, Service=orders, or a host identifier. Each distinct dimension combination identifies a distinct metric series. A producer publishing both Service=orders and Environment=production does not produce the same exact series as an alarm requesting only Service=orders.

Custom metric units create another subtle failure. If the producer publishes a metric with Count but the alarm specifies Seconds, the alarm can remain in INSUFFICIENT_DATA. Omitting the unit from an alarm is often safer when a metric consistently publishes one unit, although a metric published with several different units must first be made consistent.

Inspect the publisher's PutMetricData configuration, or the CloudWatch agent configuration, before modifying the alarm. Correcting the alarm to match a mistaken publishing format may appear to restore data while preserving an underlying instrumentation error. A clean metric naming and dimension convention makes later alarm creation more dependable.

Match the alarm period to the metric's reporting interval

When an alarm uses one-minute periods but its metric reports every five minutes, many evaluation periods have no real measurements. The alarm is asking a more frequent question than its data source can answer. CloudWatch's missing-data evaluation can fill some gaps using the policy, but it cannot create genuine measurements that were never published.

Amazon EC2 basic monitoring publishes most instance metrics at five-minute intervals. EC2 detailed monitoring makes those metrics available at one-minute intervals. EC2 status check metrics are an exception because they are available at one-minute intervals even under basic monitoring.

If you configure a one-minute CPU alarm against an instance using basic monitoring, the reporting interval may not support the behavior you expect. You can either change the alarm period to 300 seconds or enable detailed monitoring and retain the 60-second period. The right choice depends on the urgency of your alert and the additional monitoring cost.

High-resolution custom metrics can support alarm periods shorter than one minute when published at the appropriate resolution. A standard-resolution metric does not become high-resolution merely because you configure a shorter alarm period. Changing the evaluation interval without changing the publishing behavior can increase missing-data complications rather than improve alert speed.

CloudWatch evaluates alarm conditions using UTC-based metric timestamps. If your custom publisher submits timestamps that are significantly in the past or future, the expected recent evaluation window may be empty. Review both publication frequency and timestamp generation when the metric exists historically but does not appear in current evaluations.

Jake: "I selected one minute because I wanted to know about high CPU faster. Wasn't that the safer setting?"

Ethan: "Your basic EC2 monitoring normally reports CPU every five minutes. Use a five-minute alarm, or enable detailed monitoring if you need one-minute readings."

Worked example: Repair an EC2 CPU alarm that never leaves INSUFFICIENT_DATA

Consider Jake's hypothetical booking server, identified as i-0123456789abcdef0. It uses EC2 basic monitoring and reports CPU data every five minutes. He creates an alarm with a one-minute period, three evaluation periods, and a threshold above 80%.

The alarm expects three evaluation periods of 60 seconds each. However, the instance normally produces its CPU data at five-minute intervals. As a result, most of the one-minute intervals do not contain a fresh measurement, and the alarm cannot behave like a continuously populated one-minute CPU alarm.

For illustration, suppose CloudWatch has CPU averages of 24%, 31%, and 28% for three successive five-minute periods. These are normal readings, and a correctly configured CPU alarm should evaluate them as healthy. The problem is not that CPU usage is too low for CloudWatch to notice; it is that the requested one-minute configuration does not match the metric's publication frequency.

First, use get-metric-statistics with a 300-second period to inspect the actual CPU data. Next, change the alarm period to 300 seconds while preserving the intended CPU threshold and evaluation requirements. The resulting rule looks for three five-minute readings above 80%, rather than expecting three one-minute readings from a five-minute publisher.

aws cloudwatch put-metric-alarm \
  --alarm-name High-CPU-Alarm \
  --alarm-description "EC2 CPU above 80 percent" \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 3 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --treat-missing-data missing \
  --region us-east-1

The command illustrates the corrected metric alarm and intentionally omits notification actions. When updating an existing alarm, put-metric-alarm overwrites its configuration, so retrieve and preserve the original action ARNs and other required settings before issuing a production update. For a change limited to the period, editing the existing alarm in the console can be safer than constructing a partial replacement configuration.

Now suppose the illustrative CPU readings rise to 84%, 87%, and 91% across three complete five-minute periods. Each of those readings exceeds 80%, so they satisfy the configured three-out-of-three alarm rule. With continuous reporting and the applicable evaluation behavior, the alarm can transition to ALARM and run its configured actions.

Jake also has another option: enable EC2 detailed monitoring to publish one-minute CPU metrics. That would support his original shorter period, with an additional monitoring charge. If his application needs urgent overload detection, the shorter reporting interval may justify the expense; otherwise, five-minute CPU monitoring can be a practical starting point.

Choose between missing, notBreaching, breaching, and ignore

When an alarm has missing metric data, CloudWatch provides four treatment options. The setting determines how missing points participate in an alarm evaluation when insufficient real data is available. It does not repair the publisher, correct a missing metric, or force new measurements into existence.

The default option is missing. When all available data in the relevant evaluation range is missing, the alarm enters INSUFFICIENT_DATA. This expresses uncertainty instead of assuming a healthy or unhealthy condition.

The notBreaching option treats required missing data points as nonbreaching. It is useful when the metric intentionally publishes only when an undesirable event occurs, such as certain errors or throttles. In that case, an absent event can reasonably be treated as zero detected occurrences for the particular alarm.

The breaching option treats missing points as violations of the configured threshold. This is useful for a metric that should continuously report, where failure to produce a measurement indicates a problem. It is especially relevant to heartbeat-style metrics designed to represent ongoing application activity.

The ignore setting holds the alarm in its previous state when missing-data handling applies. This may be useful if a temporary telemetry interruption should not clear an already active alarm. However, it also means a previous state can persist without fresh evidence that conditions remain the same.

CloudWatch uses real data points when enough are available in its evaluation range and fills missing points only when necessary. Thus, selecting breaching does not mean every single missed sample immediately causes an alarm. You must still consider evaluation periods, datapoints to alarm, and the available real readings.

Jake: "Can I just change every missing metric to not breaching so the dashboard becomes green?"

Ethan: "That only makes silence look healthy. Use it when missing data means no event occurred, not when a server is supposed to report continuously."

Fix sparse error and throttle metrics without creating false alarms

If an error alarm remains in INSUFFICIENT_DATA while the application is healthy, the metric may be intentionally sparse. A sparse metric publishes data only when a relevant event occurs. For certain event-driven error or throttle metrics, no events means no new measurements.

An example is the ThrottledRequests metric in DynamoDB. The absence of throttle events may mean there is nothing unhealthy to report. Treating missing data as notBreaching is therefore a sensible general pattern for sparse error-style metrics.

There is an important DynamoDB-specific exception. Alarms evaluating metrics in the AWS/DynamoDB namespace always ignore missing data, even when another missing-data treatment is configured. This means your selected treatment may not have the same effect as it would for a sparse custom metric or a metric from another service.

For a custom error count, suppose your application publishes a metric only when a request fails. When failures stop, publication stops too. An alarm configured to treat missing data as missing may transition to insufficient data even though the absence of events is expected.

For that particular event-only design, notBreaching makes sense. Your alarm can treat absent measurements as nonbreaching while alerting on actual reported errors that cross the configured threshold. The decision assumes the publisher is functioning and silence genuinely represents the absence of error events.

This assumption creates an operational risk. If the entire application stops sending error metrics because its instrumentation fails, the alarm might remain green. Combine sparse error alarms with a separate heartbeat, availability check, or continuously reported activity metric when you also need to detect telemetry failure.

Alarm on metrics that are zero most of the time

When you want to alert on rare errors, distinguish an explicit zero from no measurement. A data point of zero is a genuine numeric value. A missing period contains no data point, and the missing-data setting determines how the alarm handles that absence.

If your custom metric publishes zero every minute when there are no failures, CloudWatch can evaluate those zeros normally. An error threshold greater than zero will remain healthy during zero-error periods. You do not need missing-data treatment merely because the metric's numerical value is zero.

CloudWatch Logs metric filters can publish a default value, such as zero, during periods with ingested log events but no matching events. This makes event-count metrics less sparse. However, default values are not emitted for periods in which no logs are ingested, and metric filters with dimensions cannot specify a default value.

If you need a continuously available error count independent of log ingestion, use application instrumentation that publishes an explicit zero at the expected interval. That design makes a missing measurement a genuine reporting problem rather than an expected no-error state. You can then use a second alarm to detect missing telemetry if appropriate.

For example, a custom FailedPayments metric may publish 0 every minute during normal processing and positive numbers when failures occur. An alarm with Sum and a threshold greater than zero can detect failures directly. Its missing-data policy can separately reflect whether a gap in payment telemetry is dangerous.

Another design publishes only failure events and uses notBreaching for missing data. Both designs can produce useful error alarms, but only the continuously published metric makes a reporting interruption distinguishable from a normal zero count without additional instrumentation.

Find out whether the monitored resource has stopped reporting

If an EC2 metric suddenly stops appearing, inspect the instance's actual state. A stopped instance does not continue producing normal running-instance CPU utilization readings. Your CPU alarm may consequently enter INSUFFICIENT_DATA, even though the underlying cause is that the resource is stopped.

Use the EC2 console to inspect the instance status, or run describe-instances for its state. The alarm should also be checked for an obsolete instance ID, especially after replacing or rebuilding servers. A new instance can be healthy while the alarm continues watching an old instance.

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query "Reservations[].Instances[].{
    InstanceId:InstanceId,
    State:State.Name,
    Monitoring:Monitoring.State
  }" \
  --region us-east-1

A CPU alarm is not always the appropriate mechanism for detecting whether a service is reachable. A website can be unavailable because of a failed application process, network configuration, or dependency even when EC2 CPU reporting continues normally. Conversely, a stopped instance may stop reporting CPU instead of producing a high CPU reading.

Use an availability-oriented signal when you need to detect an inaccessible booking website. This might be an application heartbeat, an externally evaluated health check, or another continuously expected service metric. Choose a signal that directly represents the condition customers care about.

If the resource is intentionally stopped on a schedule, decide what that means for the alarm. You may want the alarm to preserve an insufficient-data state or use an operational schedule that distinguishes planned downtime from incidents. Treating every stopped-resource metric as healthy can hide an unexpected shutdown.

Repair CloudWatch agent and IAM permission problems

If your alarm monitors memory, disk, or another custom system metric, the CloudWatch agent may be responsible for publishing the data. EC2's standard CPU monitoring and the agent's additional operating-system metrics are different sources. A working CPU graph therefore does not prove that the CloudWatch agent is running successfully.

Start by inspecting the agent status and its configuration. On supported systems, the CloudWatch agent control utility can report whether the service is running. Agent logs help identify configuration errors, failures to reach CloudWatch endpoints, and rejected publication attempts.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -m ec2 \
  -a status

sudo systemctl status amazon-cloudwatch-agent

sudo tail -n 100 \
  /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

The commands above apply to common Linux installations of the CloudWatch agent. Paths and service management differ for Windows and some deployment setups. Confirm the installed operating system and agent deployment method before assuming every command has the same location.

The EC2 instance role must permit the agent to publish metrics. The AWS-managed CloudWatchAgentServerPolicy provides the normal permissions used by the agent. Custom IAM policies, organization service control policies, endpoint policies, and network restrictions can still prevent successful publication.

If the agent is healthy but the metric remains absent, inspect the namespace and dimensions in the agent's configuration. The default namespace is commonly CWAgent unless the configuration overrides it. An alarm watching AWS/EC2 will not automatically receive an agent-published memory metric under CWAgent.

Jake: "My server's CPU metric works, but memory usage disappeared. Is CloudWatch partly broken?"

Ethan: "Those readings come from different publishers. EC2 sends CPU metrics, while your CloudWatch agent sends the memory metric. Check the agent and its permissions."

Make an alarm fire when a metric stops reporting

If your application must continuously report a heartbeat, missing measurements can indicate that the application or telemetry publisher has stopped. In this case, breaching can be appropriate. CloudWatch can then treat the required missing points as threshold violations instead of accepting the silence as normal.

The most reliable heartbeat design publishes a predictable value at a predictable interval. For example, an application can publish 1 every minute to a custom metric named ServiceHeartbeat. An alarm can use a threshold below 1 and treat missing data as breaching.

This combines the numerical rule with the reporting rule. A published heartbeat of 1 is healthy, while a missing interval can contribute to an unhealthy alarm evaluation. The evaluation periods determine how much sustained missing data is required before the alarm transitions.

aws cloudwatch put-metric-alarm \
  --alarm-name Service-Heartbeat-Missing \
  --namespace MyApplication \
  --metric-name ServiceHeartbeat \
  --statistic Minimum \
  --period 60 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 3 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --treat-missing-data breaching \
  --region us-east-1

To publish an illustrative heartbeat manually, use put-metric-data. In production, this publication must run from the monitored application or from a monitoring component whose health meaning is well understood. Sending one manual data point does not create a continuously functioning heartbeat.

aws cloudwatch put-metric-data \
  --namespace MyApplication \
  --metric-name ServiceHeartbeat \
  --value 1 \
  --unit Count \
  --region us-east-1

A heartbeat sent by the same application process helps detect that process failing to report. A heartbeat published by a separate supervisor has different semantics: it may demonstrate the supervisor remains healthy even when the application is not. The publisher must represent the condition you want the alarm to detect.

For highly important workflows, use an independent signal alongside application telemetry. A missing heartbeat may indicate application failure, network interruption, missing IAM permission, or monitoring infrastructure failure. The alarm detects absence of expected reporting; investigation determines the underlying cause.

Know whether INSUFFICIENT_DATA triggers notifications and alarm actions

An alarm entering INSUFFICIENT_DATA does not automatically perform every action associated with its ALARM state. CloudWatch supports actions for transitions into OK, ALARM, and INSUFFICIENT_DATA. The actions that run depend on which state transition occurs and what has been configured for that state.

For example, an SNS notification topic can be configured for insufficient-data transitions. An alarm moving from OK to INSUFFICIENT_DATA can then notify subscribers about a loss of metric visibility. If no insufficient-data action is configured, the same transition does not automatically use the topic assigned only to its ALARM state.

Most alarm actions execute when the alarm changes state rather than repeating continually while the state remains unchanged. Auto Scaling actions have different repeated-action behavior. The distinction matters when you expect a recurring notification every minute from an alarm that remains gray for hours.

You can inspect the configured action lists with describe-alarms. The AlarmActions, OKActions, and InsufficientDataActions properties show which destinations are assigned to the respective transitions. The ActionsEnabled setting indicates whether configured actions are enabled.

aws cloudwatch describe-alarms \
  --alarm-names High-CPU-Alarm \
  --query "MetricAlarms[].{
    State:StateValue,
    ActionsEnabled:ActionsEnabled,
    AlarmActions:AlarmActions,
    InsufficientDataActions:InsufficientDataActions,
    OKActions:OKActions
  }"

Be particularly cautious with EC2 stop, terminate, reboot, and recover actions. For EC2 metric alarms configured to perform these actions, leaving missing-data treatment as missing is an important safeguard against acting on a temporary metric reporting interruption. Treating a missed CPU point as proof that the instance must be terminated would be an unsafe interpretation of silence.

Understand M-out-of-N evaluation when only some data points are missing

If an alarm behaves differently from your expectations after you change missing-data treatment, inspect its evaluation periods and datapoints-to-alarm requirements. These determine how many recent breaching measurements are needed for an alarm condition. CloudWatch also retrieves additional data in its evaluation range when using its normal sliding evaluation window.

A three-out-of-three rule requires three breaching periods, while a two-out-of-three rule requires two. These settings can produce different outcomes when a data point is missing. A short gap in telemetry may be tolerable for one rule but contribute to an unhealthy evaluation for another.

Suppose CloudWatch has three real nonbreaching measurements. The missing-data policy is irrelevant because enough actual measurements exist to evaluate the alarm. When fewer real data points are available, CloudWatch may substitute the configured missing-data treatment for the required missing points.

CloudWatch also includes behavior intended to avoid premature alarm transitions when missing points surround breaching readings. As a result, reasoning only from the latest three visible points can produce a different expectation from the actual alarm evaluation. The evaluation range and special handling of certain sparse sequences matter.

When investigating surprising state changes, examine the alarm's StateReason and state history. That record provides the evaluation context behind transitions. You should also compare the actual metric data rather than assuming the missing-data setting acts as a simple replacement for every blank location on the graph.

Account for the new CloudWatch alarm warm-up period

If you recently created an alarm and it remains in INSUFFICIENT_DATA, check whether a warm-up period is configured. CloudWatch introduced configurable alarm warm-up periods on September 1, 2026. This feature addresses the delay between creating an alarm and the monitored resource beginning to publish usable measurements.

A warm-up duration can be configured from 1 to 2,880 minutes, allowing up to two days. By default, evaluation may begin early when enough metric data fills the evaluation window. A separate option can require CloudWatch to wait for the entire configured warm-up duration.

This feature is especially useful in deployment workflows where infrastructure and alarms are created together. A new application might need time to start, establish network connectivity, and begin publishing metrics. Without warm-up, a missing-data-as-breaching configuration could create notifications before the application had a reasonable opportunity to start reporting.

Warm-up is not a remedy for a permanently broken publisher. If metrics never arrive, the warm-up eventually ends and the alarm must evaluate using its configured behavior. You should still check the namespace, dimensions, publishing interval, and permissions when reporting does not begin.

For automated deployments, inspect the alarm's WarmUpConfiguration and evaluation state. An alarm in IN_WARM_UP is intentionally waiting and should not be confused with a metric alarm whose publisher has disappeared after successful operation. This distinction prevents unnecessary troubleshooting during planned startup periods.

Understand CloudWatch metric retention and old missing data

If you investigate an alarm using historical data, CloudWatch's retention periods affect which metric resolutions remain available. Recent measurements can be retrieved at finer granularity, while older measurements are retained in increasingly aggregated form. A query using an unsupported historical period may return no data despite the metric having been recorded originally.

CloudWatch retains high-resolution data points with periods shorter than 60 seconds for three hours. One-minute points remain available for 15 days. Five-minute points are retained for 63 days, while one-hour points are retained for 455 days, approximately 15 months.

For example, a query looking 30 days into the past should use a period compatible with the five-minute retained resolution. Requesting old one-minute points for that date can produce an empty result. This is a historical query limitation, not evidence that the metric was never published.

Metrics without new data for two weeks may also disappear from the console's metric browsing results and from list-metrics. That does not necessarily mean their retained historical data has been deleted. You can retrieve applicable historical measurements with get-metric-statistics or get-metric-data.

Remember that retention and live alarm evaluation are different concerns. Keeping a year's worth of aggregated metric history does not mean an alarm can use a historical reading from months ago as a substitute for missing live telemetry. Live alarms still depend on the relevant recent evaluation period.

Choose a monitoring fix without creating unnecessary costs

If you are considering detailed monitoring to fix a one-minute EC2 alarm, account for the additional CloudWatch metrics cost. EC2 basic monitoring is provided without an additional monitoring charge, while detailed monitoring incurs metric charges. Exact pricing depends on the current CloudWatch pricing terms and applicable usage.

Here is a worked monitoring-capacity comparison using one EC2 CPU alarm. With basic monitoring, one 300-second interval represents five minutes of observation, or 12 such intervals per hour. Detailed monitoring can provide 60 one-minute observations per hour for that metric instead.

Over a 24-hour day, this means the reporting cadence represents approximately 288 five-minute intervals or 1,440 one-minute intervals. The latter provides five times as many intervals, but increasing granularity does not automatically make a badly chosen threshold more meaningful. You still need to select the correct statistic, threshold, and evaluation window for your workload.

For a small repair-booking website, a five-minute alarm might provide sufficient warning if short-lived CPU spikes are not operationally important. A latency-sensitive application may justify one-minute monitoring to detect sustained trouble sooner. Use the shortest interval that your telemetry can actually support and your response process can use.

Publishing a custom metric more often just to clear an insufficient-data state is rarely the fix. First decide whether the metric should be continuous, sparse, or a heartbeat. A sparse error metric can often use suitable missing-data treatment without publishing extra measurements solely for the sake of producing a green alarm.

If you add custom heartbeat metrics or additional alarms, evaluate the resulting CloudWatch charges separately. These can include custom metrics, alarms, and high-resolution alarm features. An operationally useful alarm design justifies its cost by answering a meaningful reliability question, not simply by keeping dashboards visually tidy.

What to do when the alarm still has insufficient data

If your alarm stays in INSUFFICIENT_DATA after reviewing its metric identity and period, work backward from the publisher. Confirm that the source is actually producing measurements and that the timestamps fall within the expected interval. A correctly configured alarm cannot evaluate current readings that are never sent.

When troubleshooting an EC2 metric, inspect whether the instance is running and whether detailed monitoring matches the alarm period. When troubleshooting a custom metric, examine the publisher's configuration, error logs, IAM permissions, network access, and unit selection. For metric math alarms, inspect the component metrics and whether the final expression produces a usable time series.

Next, inspect recent alarm history and evaluation state. An alarm in a configured warm-up period may be functioning as designed. An alarm reporting evaluation errors requires a different response from one that merely has sparse input data.

Collect the alarm name and ARN, AWS account and Region, selected namespace, dimensions, statistic, unit, evaluation periods, missing-data treatment, and a time range demonstrating the problem. Save the output of describe-alarms and the corresponding get-metric-statistics request. For custom metrics, include the publisher-side logs without exposing secrets.

If these details still do not explain the behavior, use an AWS Support case appropriate to your account's support entitlement. Clearly describe whether the metric is missing from the underlying API results or only from alarm evaluation. This distinction gives the investigation a concrete starting point.

Jake: "What if I change the period and the alarm is still gray?"

Ethan: "Then the period wasn't the only problem. Follow the metric back to its source, and compare what the publisher sends with what the alarm requests."

Frequently asked questions about CloudWatch INSUFFICIENT_DATA alarms

What does INSUFFICIENT_DATA mean in CloudWatch?

It means the alarm cannot currently determine the required state from available metric data, or it has not yet started evaluating. The alarm may be newly created, lack enough measurements, or be in a warm-up period. The state is not automatically an AWS service error.

Why is my CloudWatch alarm stuck in INSUFFICIENT_DATA?

Common causes include missing metric publications, incorrect dimensions or namespace, a period shorter than the reporting frequency, wrong units, or a stopped resource. Custom metrics may also stop reporting when the publishing agent fails or lacks permissions. Compare the alarm configuration with actual metric data before changing the threshold.

Does INSUFFICIENT_DATA trigger CloudWatch alarm actions?

It can trigger actions configured specifically for transitions into the INSUFFICIENT_DATA state. It does not automatically execute actions configured only for the ALARM state. During a configured alarm warm-up period, alarm actions do not run.

How do I fix a CloudWatch alarm with no data points?

Inspect the exact metric identity, including namespace, name, dimensions, statistic, and unit. Use get-metric-statistics with an appropriate period and recent UTC time range. If no data is returned, investigate the publisher or the query settings.

What is the best TreatMissingData setting for CloudWatch alarms?

The best setting depends on what missing measurements mean for the metric. Use notBreaching for suitable sparse error metrics, breaching for continuously expected heartbeats, and missing where absence means uncertain health. Use ignore when retaining the prior state is the intended behavior.

How can I make a CloudWatch alarm fire when a metric stops reporting?

Use a metric expected to publish continuously and configure missing data as breaching. Set evaluation periods that reflect how long missing telemetry must persist before the alarm fires. A periodic heartbeat is usually more reliable for this purpose than a metric that naturally publishes only during events.

Why does an EC2 CPU alarm need detailed monitoring for one-minute periods?

EC2 basic monitoring normally provides CPU metrics at five-minute intervals. Detailed monitoring provides one-minute intervals for supported EC2 metrics, enabling more consistently populated one-minute CPU alarm periods. EC2 status check metrics already have one-minute availability under basic monitoring.

Why does my CPU alarm show INSUFFICIENT_DATA even when EC2 is running?

The alarm may be using an unsupported reporting cadence, wrong instance ID, wrong Region, or incorrect metric configuration. A running instance does not guarantee that every alarm request matches its published measurements. Retrieve the CPU metric directly and compare its actual data with the alarm's settings.

How do I alarm on a CloudWatch metric that is zero most of the time?

If the metric reports explicit zeros, configure a threshold that detects positive or otherwise unhealthy values. If the metric reports only when an event occurs, consider notBreaching for missing periods. Use separate availability monitoring when the metric publisher itself must remain healthy.

Is a missing CloudWatch metric the same as a zero value?

No. Zero is a real reported measurement, while missing indicates that no applicable measurement is available for that period. CloudWatch uses the missing-data policy to decide how to evaluate absent points when needed.

Why does my CloudWatch custom metric alarm have insufficient data?

Check whether the custom metric is publishing to the expected namespace, dimensions, and unit. Confirm the publishing application or CloudWatch agent has permission and network access to send the data. Also inspect timestamps and whether the publishing frequency matches the alarm period.

Can the wrong CloudWatch metric unit cause INSUFFICIENT_DATA?

Yes. An alarm specifying a unit different from the unit used by the publisher can fail to retrieve matching measurements. Remove an unnecessary unit specification or align it with the actual metric publication. Keep the publisher consistent if multiple units have been used for the same metric identity.

How long does CloudWatch keep metric data?

High-resolution data below one-minute periods is retained for three hours, one-minute data for 15 days, and five-minute data for 63 days. One-hour aggregated data is retained for 455 days, approximately 15 months. Historical queries must use periods compatible with the retained resolution.

Why does get-metric-statistics return an empty Datapoints array?

The requested metric might have no data for the specified interval, or the query could use incorrect dimensions, Region, statistic, unit, or period. Older data may require a coarser period because of metric retention rules. An empty array does not establish that the resource has never published any metric data.

What happens if I set TreatMissingData to notBreaching?

CloudWatch treats required missing data points as healthy when applying the missing-data policy. This can prevent false alarms for sparse event metrics. It can also hide a reporting failure when a continuously expected metric stops publishing.

Why is my new CloudWatch alarm still insufficient after creation?

New alarms begin in INSUFFICIENT_DATA until they can be evaluated. A configured warm-up period can intentionally delay evaluation while the metric publisher starts. If the state persists unexpectedly, inspect the metric data and the alarm's warm-up configuration.

For Jake's booking website, the important result is not merely changing a gray alarm into a green one. It is ensuring that CloudWatch evaluates the correct metric at the right frequency and that a missing measurement receives the treatment its meaning deserves. If your own alarm is still stuck, begin with its metric identity and actual data points, then choose the missing-data policy deliberately. I hope your next CloudWatch alert tells you something useful about the system, rather than leaving you wondering whether the monitoring itself is working.

Revision note. Written October 19, 2026. "No news is good news," the saying goes; with CloudWatch alarms, no data means nothing until you decide what it means.