Monthly CloudWatch cleanup audit for waste and dead alarms

On the first Monday of every month at 9am, audit my Amazon CloudWatch setup for waste and quiet misconfiguration, then report what should be cleaned up. This workflow must only ever read and recommend. It must never delete, disable, mute, or edit an alarm, dashboard, or metric on its own. A quiet alarm is sometimes deliberate, and a human needs to make that call, so every finding is a recommendation for a person to approve.

Start with Describe Alarms to pull every alarm in the account, paging through until there are no more results, and include both metric alarms and composite alarms. From that full list, flag the two silent failure modes. First, alarms parked in INSUFFICIENT_DATA, which usually means the resource behind them was deleted, renamed, or stopped reporting, so the alarm looks healthy but is watching nothing. Second, alarms with no actions attached, meaning nobody is ever told when they fire. Treat an alarm as unactioned if its alarm, OK, and insufficient-data action lists are all empty, and separately call out alarms that do have actions configured but have actions disabled, since those are silently inert too.

Then use Describe Alarm History across the last 90 days to sort the rest into dead weight and noise. Dead weight is alarms that never changed state at all in that window, which are candidates for removal or for a threshold that would actually trip. Noise is alarms that changed state more than 20 times, which have almost certainly been tuned out by the team and need their thresholds revisited rather than deleted. Make the 20 state-change threshold an editable value near the top of the workflow. If the account has a large number of alarms, prioritize history lookups over alarms that are not already flagged as unactioned or stuck, so the run stays within a sensible number of calls, and note in the report if any alarms were not fully checked.

Next use List Dashboards to count how many dashboards exist and compare that against the three that AWS includes at no cost, so anything beyond three is billable. Then use List Metrics filtered to my non-AWS namespaces, meaning any namespace that does not begin with the AWS prefix, to count custom metrics, which bill per metric per month. Skip the standard AWS service namespaces, since those are not what drives custom metric charges.

Do not attempt to audit log groups, log retention, or log ingestion volume. This connection covers metrics, alarms, and dashboards only, and logs live behind a separate service, so leave logs out of the report entirely rather than guessing at them.

Group everything into a prioritized cleanup list with a rough monthly dollar estimate per category. Use these as editable default rates and state the assumptions in the report: custom metrics at 0.30 US dollars per metric per month for the first 10,000, dashboards at 3 US dollars per dashboard per month beyond the three free ones, and an editable default for the per alarm monthly price with standard resolution alarms commonly published at around 0.10 US dollars. Present the total as an approximate figure, never as an exact invoice number, and say plainly that AWS pricing varies by region and changes over time. Rank the categories by a combination of dollars recoverable and risk, and put unactioned or stuck alarms high in the list even where the dollar value is small, because those represent real monitoring blind spots rather than just cost.

Post the summary to my Slack ops channel with Send a Message. Keep it skimmable: a one-line headline with the approximate monthly total and the number of items found, then the prioritized categories with a count and a rough cost each, then the single most important thing to fix first. Do not paste the entire itemized list into Slack, and link to the Linear issue for the detail.

Then open a single Linear issue with Create Issue holding the itemized checklist, so the cleanup actually gets an owner. One issue per run, not one per finding. Title it with the month and the approximate recoverable amount, and write the description in Markdown as checkbox items grouped by the same categories used in the Slack summary, naming each specific alarm, dashboard, or metric so someone can work through it directly. Include the pricing assumptions used and a short note that every item needs human review before anything is removed.

Note in both outputs that this audit covers only the region the CloudWatch connection is configured for, since monitoring data is region scoped and never cross region, and that teams running several regions can duplicate this workflow once per region.