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.
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?
You are right, and it's not something I'd fully clocked until you said it - I've been distributing this like something people go looking for when actually the moment it'd land is right after a bad week, not on a random Tuesday.
The honest version: I don't yet have a hook into that moment. No integration with incident tools, no "just had a rough week?" trigger. Right now it's purely "here's a link, try it" which assumes the motivated mindset you are describing is already there.
If you're up for a look - the thing I'd most want eyes on is exactly this: whether there's a lightweight way to catch that post-incident window without needing deep integration with any tools right out of the gate.
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.
I appreciate that. The CFN template was specifically designed to eliminate the “what did I just give this thing access to” hesitation before it begins. Your local CSV approach is another valid option honestly. What’s the name of it I’d like to take a look at.
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!
Appreciate the structure on this - three solid points.
Fix output: right now it's copy-paste - each finding generates the actual AWS CLI command, but you still run it yourself. One-click / Terraform-generation is a step further than that and a fair ask, don't have it built, but in the roadmap.
Security friction: no argument - CFN read-only lowers the bar but doesn't zero it out. Local script path is on the list, not built yet.
Audience: yep, that's exactly who this is built for.
Thanks for taking the time to write this out.
Good to know the local script path is already on the radar. Makes sense to nail the core output first before adding one-click automation. Good luck with it.
Thanks. Appreciate your comment.
You are most welcome.
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?
Sure, would love to. Here [email protected]
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
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.