# Amazon CloudWatch Alarm

> CloudWatch alarms bill per alarm per month, with higher rates for high-resolution and composite alarms. An alarm watching a deleted resource keeps billing while it can never fire usefully. ZopNight discovers alarms on the 6-hour cycle, recommends cleanup of orphaned and broken ones, and attributes per-alarm cost from Cost Explorer or CUR 2.0.

Source: https://zop.dev/integrations/aws/cloudwatch-alarm
Updated: 2026-08-19

---

A CloudWatch alarm watches a metric and triggers actions, billed per alarm per month with higher rates for high-resolution and composite alarms. Alarms referencing deleted resources keep billing while alerting on nothing.

## Metered per alarm, forever

Every alarm bills a monthly fee for existing: standard-resolution alarms at the base rate, high-resolution alarms (sub-minute periods) at a premium, and composite alarms (those combining other alarms with boolean logic) at their own rate. The fee is independent of whether the alarm ever changes state. That combination of small per-unit cost, unbounded population, and no expiry is exactly the profile that produces thousands-strong alarm estates in mature accounts, created by autoscaling policies, dashboards-as-code, and every team's monitoring stack since the account opened.

## Broken-watch detection

A dedicated provider discovers every alarm on the 6-hour cycle, with per-alarm cost from Cost Explorer or CUR 2.0. The cleanup recommendations target two failure classes. Orphaned alarms watch metrics from resources that no longer exist: an instance ID that was terminated, a load balancer that was deleted. Such alarms sit permanently in INSUFFICIENT_DATA while billing monthly. Broken alarms have actions pointing at deleted SNS topics or disabled autoscaling policies, so even a genuine breach notifies nobody. Both categories are worse than useless: they cost money and erode trust in the alarms that matter.

## Why alarm estates rot

Alarms are created alongside resources but deleted separately from them. Terminating an instance does not delete its CPU alarm; destroying a Terraform stack leaves manually added alarms behind; and autoscaling deletes policies without deleting the alarms that referenced them. Monitoring migrations, whether to Datadog, Grafana, or a new alarm taxonomy, reliably leave the previous generation intact "for reference".

## Sweeping the alarm list

CloudWatch's All alarms view can be filtered by state; a long-standing INSUFFICIENT_DATA population is the orphan shortlist. Checking a sample's metric dimensions against live resources confirms the diagnosis, and deleting an orphaned alarm carries no risk beyond losing a record that something once existed.