# Monthly CloudWatch cleanup audit for waste and dead alarms

> On the first Monday of every month, find the alarms nobody watches and the monitoring you quietly pay for, then get a costed cleanup list in Slack and Linear.

- Workflow type: agent
- Services: Amazon CloudWatch, Slack Bot, Linear
- Categories: Engineering, Finance
- Published: 2026-08-10

## What it does

- Reviews every alarm in your account and flags two quiet failure modes: alarms sitting with no data coming in, which usually means the resource behind them was renamed or deleted, and alarms with nobody attached to them, which means they fire into thin air and no one is ever told.
- Looks back over 90 days to separate dead weight from noise. Dead weight is alarms that have never once changed state. Noise is alarms that have flipped back and forth so many times the team has learned to tune them out.
- Counts your dashboards and your custom metrics, the two parts of monitoring that quietly add to the monthly bill, and puts a rough dollar figure next to each category so you can see what the mess is costing.
- Posts a prioritized summary to your Slack ops channel and opens a single Linear issue holding the itemized checklist, so the cleanup gets a real owner instead of being a screenshot someone forgets.

## What you'll need

- An Amazon Web Services account with monitoring set up, connected for the region you want reviewed
- A Slack workspace and the ops channel where the monthly summary should land
- A Linear account and the team that should own the cleanup work
- Nothing gets changed in AWS, so read-only access is enough

## Prompt

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.

## How to customize

- Change the timing. First Monday at 9am matches how most teams review cloud spend, but any monthly or quarterly cadence works just as well.
- Adjust what counts as noisy. The default flags anything that changed state more than 20 times in 90 days, which you can raise for busy production accounts or lower for quiet ones.
- Edit the pricing assumptions. The dollar estimates use published list prices as starting defaults, and you can swap in the rates that match your region and agreement.
- Point the outputs somewhere else, such as a different Slack channel per team, or a specific Linear project for infrastructure work.

## FAQ

### Will this delete or switch off any of my alarms?

No. It only reads and recommends. Nothing is deleted, disabled, or edited in your AWS account. This is deliberate, because a quiet alarm is sometimes quiet on purpose, and a person needs to make that call before anything is removed.

### Does it cover all of my AWS regions at once?

No. Monitoring data is tied to a single region, so the audit covers the region your connection is set up for. If you run several regions, duplicate the workflow once per region and point each copy at the right one.

### How accurate is the monthly dollar estimate?

Treat it as a well-informed ballpark, not an invoice. It uses published list prices as defaults, and real costs vary by region, by agreement, and over time. It is meant to help you rank what to clean up first, not to reconcile your bill.

### What makes an alarm count as noisy rather than useful?

By default, any alarm that changed state more than 20 times in the last 90 days. That much flapping usually means the threshold is wrong rather than that something is genuinely broken 20 times over, and teams tend to start ignoring those alerts.

### Do I need to be an engineer to make sense of the report?

No. The summary is grouped into plain-English categories, ranked by what is worth fixing first, with a rough cost next to each group. The detailed checklist lives in the Linear issue for whoever picks up the work.

Use this prompt in General Input: https://www.generalinput.com/prompts/monthly-cloudwatch-cleanup-audit-for-waste-and-dead-alarms