Built a free AWS alert audit tool - zero real users so far, would love your eyes on it
I'm a DevOps engineer, and the thing that's always kept me tense is not knowing what CloudWatch alerts I'm missing until something goes down silently and I find out the hard way. There's no easy way to look at an account and just know "am I actually covered here." So I built a free tool that scans an AWS account (read-only) and shows exactly that - missing alerts, noisy ones, and critical signal getting buried in noise.
It's a side project alongside my full-time job, and honestly - I haven't gotten a single confirmed real user yet. I've tried a bit of outreach and it hasn't landed, so I'm trying this community directly instead.
How it works: connects via a public CloudFormation template you can read line-by-line before creating anything - about 50 read-only permissions (describe/list/get only, nothing that writes or deletes), no AWS access keys involved. Takes ~2 min.
Real example report if you want to see the output first, no signup needed: https://www.nuberio.com/audit/report/ZCjG84glc36z
Try it yourself: https://www.nuberio.com/audit
Would genuinely appreciate any feedback - including "this doesn't solve a real problem" if that's honestly what you think.
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.
Thanks for sharing your view Aryan.
To tackle the trust issues, I have shared the CFN template that gets deployed publicly. Anyone could check the template before deploy. Also, there is a section on the exact same page, where I have mentioned all the services and the required access the audit would use.
That would help someone who is landing on the page, to review the permission before running the audit.
Thanks for the additional context. I'd enjoy continuing the conversation outside the thread if you're open to it. What's the best email to reach you on?
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:
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.
Appreciate the walkthrough - that's rare.
Agreed on all three. Steps-before-value and progress visibility are on the list. The CLI-block-by-default thing was actually a real bug - one card type wasn't collapsing like the rest. Fixed.
You're right that trust is the harder problem here, not the audit logic. That's the one I'm actually rethinking.