A useful Amazon CloudWatch alarm detects a condition that matters to a workload and gives someone or something a clear next step. Set the threshold from a service objective, a known resource limit, or an operational failure condition. Then tune the period, number of breaching data points, and missing-data behavior to match how the metric is published and how quickly the team must respond.

  • Alert on customer impact or an actionable limit, not simply a value above the historical average.
  • Use DatapointsToAlarm and EvaluationPeriods to balance detection speed with short-lived noise.
  • Decide what missing data means for each metric; CloudWatch does not always apply the configured missing-data choice.
  • Use metric math, percentile statistics, anomaly detection, and composite alarms only when they express a clearer operational condition.

Choose metrics and thresholds

Start with the question the alarm should answer: are customers receiving errors, is a queue falling behind, or is a resource nearing a limit that could affect service? Select a metric and statistic that measure that condition. For example, a request error count can show failures, while an error ratio puts that count in the context of traffic. For latency, an upper percentile can reveal slow requests that an average hides. Resource metrics such as CPU are useful when they explain a capacity risk or help a responder act before customer impact.

Set the threshold from the workload's service objective, a tested capacity boundary, or a known failure mode. Historical data helps you understand normal variation, time-of-day patterns, and the lead time available to respond; it does not by itself define what is acceptable. A CPU threshold slightly above its average, for example, may page too late or on harmless spikes. Define what action follows the alarm and who owns that action. For a broader view of choosing workload signals and actionable alerts, see the site's AWS monitoring guide.

Static thresholds and anomaly detection

A static threshold is a good fit for a clear boundary, such as a maximum supported connection count or an error rate tied to a service objective. It is straightforward to explain and test. A static value can be a poor fit when a metric changes with regular hourly, daily, or weekly demand.

CloudWatch anomaly detection models expected metric behavior and creates a band. You choose whether values above, below, or outside that band should breach. Review the band against the workload and exclude exceptional periods such as outages or unusual deployments from training when appropriate. A learned band describes historical behavior; it does not decide whether that behavior meets a service objective.

Percentile thresholds

A percentile describes the distribution of observed metric values. A p95 latency of 800 ms means 95% of the recorded observations are at or below 800 ms for the selected statistic and period; it does not necessarily mean that 5% of users had a slow experience. Use a percentile when the metric has enough samples and each observation represents the behavior you care about.

For percentile alarms, CloudWatch lets you choose whether to evaluate low-sample periods or keep the current alarm state until samples are sufficient. For example, a p99 alarm has low sample count below 1,000 observations in an evaluation period. See AWS's guidance on percentile alarms and low data samples before relying on a high percentile for a low-traffic metric.

Set periods and datapoint conditions

The Period groups metric data into each alarm datapoint. EvaluationPeriods is the number of recent datapoints CloudWatch considers (N), and DatapointsToAlarm is how many of them must breach (M). With a one-minute period and no missing datapoints, a 2-of-3 condition goes to ALARM when any two of the three recent one-minute datapoints breach; they do not need to be consecutive. When M and N are equal, every datapoint in that window must breach.

Choose a period the metric can support and a window that fits the response. Shorter periods can detect a fast failure sooner, but can make the alarm more sensitive to bursts and metric gaps. Longer periods smooth noise but delay detection. Standard-resolution metrics use periods of at least one minute. High-resolution custom metrics can be alarmed on at 10, 20, or 30 seconds, with more frequent evaluations and additional cost. Match the period to the metric's publication cadence as well as the incident's time scale; a one-minute alarm period does not create one-minute data if the metric only arrives every five minutes. For example, EC2 basic monitoring sends most metrics every five minutes but status checks every minute; see AWS's EC2 metric schedule and the site's EC2 basic and detailed monitoring guide for the details and exceptions. AWS also documents the M-out-of-N behavior and high-resolution periods.

Metric alarms use a sliding evaluation window by default. The window moves forward as CloudWatch reevaluates the alarm. A wall-clock window aligns periods to calendar boundaries and a selected time zone, which can suit scheduled jobs, daily reports, or backups where a completed calendar interval matters. It is evaluated at the same frequency as a sliding window, but reflects new data only after the calendar period ends.

When Period multiplied by EvaluationPeriods is greater than one day, CloudWatch evaluates a multi-day alarm once per hour. With the default sliding window, evaluation uses metric data through the current hour's :00 boundary, so a batch failure just after that point can wait for a later hourly evaluation. With a wall-clock window, the evaluated interval is calendar-aligned and only includes completed periods. Do not use a multi-day window when an incident needs minute-level detection; see the CloudWatch alarm evaluation guide for these timing details.

Use metric math and composite alarms

Rates, ratios, and units with metric math

Metric math can turn related metrics into one alarm signal. A ratio can make an alert meaningful at both low and high traffic. For example, if errors and requests are aligned metric IDs, IF(requests > 0, errors / requests) produces an error ratio only when requests are present. A threshold of 0.02 means 2%; if the expression multiplies the ratio by 100, compare it with 2 instead. Keep both metrics on the same period and make the expression's units and threshold agree.

Metric units are part of the metric definition, not a conversion instruction. CloudWatch's Unit parameter filters datapoints; it does not scale their values. Publish values consistently with one unit, and avoid specifying a unit filter unless needed: if a metric has been published with multiple units, alarm evaluation without a filter can be unpredictable. See the PutMetricAlarm API reference for the unit behavior. If no requests should mean healthy, choose missing-data behavior to match that intent; the expression above omits a datapoint when its denominator is zero.

Composite alarms and action suppression

A composite alarm evaluates the states of other alarms with AND, OR, and NOT rules. Use one when a notification should depend on a useful combination of signals—for example, when elevated application errors and a database connection alarm occur together. Keep the underlying metric alarms: they still evaluate and can retain their own actions.

Composite alarms cannot perform EC2 or Auto Scaling actions. They can route notifications and supported alarm actions, but use a metric alarm for a native EC2 or scaling action; see the CloudWatch alarm documentation for supported composite actions. Composite action suppression can delay or prevent actions while a suppressor alarm is active; it does not hide the component alarm states. The configured wait and extension periods allow time for suppressor and composite states to settle, so choose them with the metric evaluation cadence in mind. See AWS's docs on suppressing composite alarm actions.

Handle missing data and review alarm behavior

Choose missing-data treatment deliberately

Missing data can mean a collector stopped, a resource became unavailable, or an event-only metric simply had nothing to report. The options are missing (the default), notBreaching, breaching, and ignore (keep the current state). Choose based on the metric's publishing contract: a missing point for a continuously reported health signal may indicate a monitoring problem, while an event count that reports only when an event occurs may be quiet during healthy operation.

CloudWatch retrieves extra datapoints when evaluating a sliding window. If it finds enough real datapoints, it evaluates those and may not need the configured missing-data treatment. The setting is used to fill only when there are too few real datapoints. Also, alarms on metrics in the AWS/DynamoDB namespace always ignore missing data, even if another setting is configured; this override is described in the PutMetricAlarm API reference. Check AWS's detailed guide to alarm evaluation with missing data before treating silence as zero or as a failure.

Actions follow alarm state changes

CloudWatch alarms have three states: OK, ALARM, and INSUFFICIENT_DATA. Most configured actions run when the alarm changes state, not continuously while it stays in that state. Auto Scaling actions are an exception: CloudWatch continues invoking them once per minute while the alarm remains in its new state. Keep this behavior in mind when choosing a scaling policy and when testing notification delivery. For a list of supported actions and their behavior, see CloudWatch alarm actions.

Troubleshoot an alarm

When an alarm behaves unexpectedly, inspect its graph and history before changing the threshold. Confirm the namespace, dimensions, statistic, unit, and period identify the intended metric. Then compare the most recent datapoints with M and N, check whether the metric arrived on time, review missing-data and low-sample settings, and confirm the notification or action is configured for the state transition you expect. Alarm history and the state reason help distinguish a threshold problem from missing input or an action-routing issue.

After an incident or a noisy page, adjust the condition only when the evidence points to a mismatch: wrong metric, threshold unrelated to user impact, overly short window, incorrect missing-data assumption, or an action without a clear owner. Review the result against real traffic and failure scenarios so the alarm remains both useful and actionable.

Build alarms around the response

Choose a metric that expresses a real service or resource condition, set a threshold from an objective or limit, and tune M-of-N timing to the metric's resolution and response window. Treat missing data according to how the metric is emitted, and verify that every alarm action reaches an owner or a safe automation. A concise, tested alarm gives responders more value than a large collection of thresholds without a clear next step.

FAQs

What do M-out-of-N settings mean?

EvaluationPeriods is N, the number of recent datapoints considered. DatapointsToAlarm is M, the number that must breach. For example, with a one-minute period, 2 of 3 means two breaching points among the three most recent minutes; the points do not have to be consecutive.

Why is an alarm in INSUFFICIENT_DATA?

CloudWatch has not received enough usable datapoints to determine whether the condition is breaching. Check the metric's dimensions, publishing cadence, period, and data pipeline, then review the configured missing-data behavior. Some metrics report only when events occur, so no datapoint does not always mean zero or failure.

Will an alarm repeat its action while it stays in ALARM?

Most alarm actions run on a state transition and do not repeat just because the alarm remains in ALARM. Auto Scaling actions are the exception and repeat once per minute while the alarm stays in its new state. Alarm state can also change while a composite alarm's actions are suppressed; suppression affects those actions, not the underlying states.