Built a free AWS alert audit tool - zero real users so far, would love your eyes on it

The three buckets you check for (missing, noisy, buried) miss a fourth failure mode I think: an alarm that exists, looks correctly configured, and sits in OK forever without actually watching anything. That happens whenever the underlying metric stops emitting, a renamed ASG, a redeployed Lambda alias, a swapped ECS task, and it comes down to each alarm's TreatMissingData setting. Set to notBreaching or ignore, the alarm state never moves, so DescribeAlarms reports it as healthy indefinitely. Since you're already pulling alarm config, cross-checking each alarm's metric against GetMetricData for actual recent datapoints (not just current alarm state) would catch that directly, it's a failure mode a coverage scan can't see just by confirming an alarm object exists. We hit the same shape of bug once: a background worker whose own canary stayed green while the thing it was supposed to be watching had quietly died.

Yeah, this is actually a pretty relatable problem. It’s easy to keep adding CloudWatch alarms without ever checking whether the important parts of an AWS account are really covered.

I like the read only approach too. Not needing AWS access keys makes it feel much easier to test without worrying about giving the tool unnecessary permissions.

I’d be interested to see what kinds of missing alerts it catches in a real production setup. Getting those first few users is always the hardest part with side projects. Hope you get some good feedback from the community.

Zero users on a free tool usually isn't a distribution problem, it's that alert fatigue is something people complain about but don't schedule time to fix. It's chronic, not acute — nobody wakes up and decides today is audit day.

Which makes me wonder about the entry point rather than the tool. Right now someone has to already believe their alerting is bad and go looking. Is there a version where it hooks into a moment that already exists — after an incident review, or after a noisy week — when the pain is fresh enough that someone would actually click?

Happy to look at it properly. What's the one thing you'd most want an outside pair of eyes on?

Smart approach — using a public CloudFormation template with reviewable read-only permissions is a clean way to lower the "will this break my account" fear. that's usually the biggest blocker for any AWS tool.

I went the opposite direction in the same space: no AWS permissions at all, just a local CSV scan. tradeoff is more manual but zero trust required. different teams will prefer different sides of that line.

the example report is a good move — lets people see the output before committing any setup.

This is a really solid utility that hits on a very real pain point for DevOps engineers—alert fatigue and blind spots are a nightmare to manage. A few quick thoughts to help you get those first real users:

Overcoming the Security Friction: Asking engineers to connect a read-only CloudFormation template to their AWS environment is a tough sell for a brand-new tool, even with strict read-only permissions. Highlighting that your code is open-source or providing a CLI script they can run locally inside their own AWS environment could instantly eliminate that security barrier.

Productizing the Output: The sample report is clean, but make sure the recommended fixes are as actionable as possible—like generating the Terraform or AWS CLI commands to deploy the missing alerts in one click.

Targeting the Right Audience: Instead of broad outreach, try reaching out directly to small-to-medium startups without dedicated 24/7 DevOps teams. They are the ones most likely to have unmonitored infrastructure slipping through the cracks.

Solving your own headache as an engineer is always a great start. Don't get discouraged by the initial traction—getting users to connect cloud accounts just takes extra trust-building!

One thing I'd be paying attention to is whether the challenge is trust or demand.

Someone can agree this is a real problem and still hesitate to connect a production AWS account. Those look like "no users" from the outside, but they're very different problems to solve.

I went through the entire flow, including reviewing the CloudFormation template, connecting an AWS account, waiting for the scan, and reading the report.
Overall, it felt trustworthy. I especially liked that every permission is explained and the template is publicly visible before deployment.

A few things stood out to me as a first-time user:

• The onboarding has quite a few steps before you get to the actual value. Even though I'm comfortable with AWS, I still paused for a second before creating the stack.
• The live scan is a nice touch, but I'd love to see more visible progress as different services are being checked.
• The report is really informative, but seeing a huge block of CLI commands right away felt a bit overwhelming. I think collapsing them by default and focusing first on the explanation and impact would make the report much easier to digest.

Overall, I don't think the audit itself is the challenge. I think the bigger challenge is helping first-time users feel confident enough to click "Deploy" and get through that initial setup.