SRE teams already know it's Azure. They just can't automate that knowledge yet.
There's a Reddit thread from February 2026 where sysadmins are venting about the Azure outage. Not about Azure being down, that's expected. About the 200+ Defender sensor alerts that flooded their queues while they already knew it was a provider issue. One comment has 340 upvotes: 'we spent 45 minutes silencing alerts we knew were fake before we could even start the actual incident response.'
That's the problem. And I think it's buildable in a weekend, with a real path to money.
When a major cloud provider goes down, monitoring tools don't know the difference between 'your app is broken' and 'Azure is broken.' They just see connectivity failures and start screaming. Your on-call engineer gets paged 80 times for the same root cause, spends an hour writing manual suppression rules, and by the time things are quiet, the outage is already half over.
Every existing tool in this space (PagerDuty, Opsgenie, FireHydrant) does alert deduplication based on internal signals. None of them cross-reference the Azure status page, BGP anomaly feeds, or Downdetector to say 'this alert cluster looks like a provider outage, not a you problem.'
That's the gap. The Outage Triage & Alert Suppression Engine sits between your monitoring stack and your on-call tool and makes that connection automatically.
Seriously. Don't touch Cursor yet.
The validation test here is unusually clean. Build a no-code prototype in Zapier or Make: webhook from Alertmanager, check the Azure Status Page RSS feed, if an incident is active, post to a '#suppressed-alerts' Slack channel instead of paging. That's it. Takes maybe two hours to set up.
Then go to that r/sysadmin Azure outage thread and DM the top commenters. Offer to set this up free for their team in exchange for a 30-minute call. The pitch is almost embarrassingly simple: 'I built something that would have suppressed those 200 alerts last month. Want to try it?'
Your success metric before writing a single line of product code: 5 teams run the prototype for 2 weeks, and at least 3 say they'd pay $29/month to keep it. If you can't hit that, the idea has a distribution or pricing problem that no amount of engineering fixes.
I'd give yourself two weeks to find out.
Four weeks solo. Here's how I'd break it down:
Week 1: Webhook ingestion from Prometheus Alertmanager. Configurable routing rules. This is mostly glue code.
Week 2: External feed poller. Azure, AWS, GCP status pages. One BGP anomaly feed (Cloudflare Radar has a free tier). Confidence scoring logic that combines feed status with alert volume and pattern.
Week 3: Audit log UI (this matters more than you think, teams need to see what got suppressed and why), Slack/Teams routing for the 'global incident detected' channel, Stripe billing.
Week 4: Onboarding flow. Docs. The boring stuff that determines whether your first 10 customers actually stick around.
Stack: Next.js, Supabase, Inngest for the feed polling jobs, Vercel for hosting. All managed. No DevOps rabbit holes on a solo build.
The 'aha moment' is specific: user sees their first real outage handled, Slack gets one message saying '84 alerts suppressed, Azure outage detected, confidence 91%' instead of 84 individual pages. That usually happens within the first two weeks of setup if you onboard them before the next big outage season.
Freemium: free up to 2 integrations and 500 suppressed alerts per month. $29/month for up to 5 integrations. $79/month for SSO, audit log exports, multi-channel routing.
At $79/month average, 18-month retention (which is realistic for SRE tooling once it's embedded in workflow), you're looking at ~$1,400 LTV. Fixed costs at small scale are maybe $1,400/month total. You break even at 18 customers.
The margin is good, around 88%, because the primary costs are feed API access and infrastructure. You're not running GPU clusters.
I want to be honest about the structural problem with this idea, because it's a real one.
Status pages are delayed 10 to 30 minutes behind actual outage onset. That delay is the worst possible window, because that's exactly when alert storms are most intense. So your suppression engine will be least useful precisely when teams need it most. BGP feeds and Downdetector help close that gap, but they don't eliminate it. If you ship this and a team trusts a 91% confidence suppression during that early window and it's wrong, a real incident gets buried. That's not just a churn event. SRE communities are tight. Word travels fast.
The mitigation is building alert pattern recognition as a secondary signal. A sudden spike in a class of alerts across multiple customers is itself a leading indicator, before any status page updates. That's actually a legitimate moat: cross-customer pattern data that no single-org PagerDuty rule set can replicate.
The other risk: PagerDuty has $406M in funding and 500+ integrations. If this product gets to $1M ARR, they will ship 'External Outage Correlation' as a Business tier feature within 18 months. That's not speculation, it's how their product roadmap works. Your defense is going vendor-neutral (works alongside PagerDuty AND Opsgenie AND Grafana OnCall simultaneously) and building the data flywheel fast enough that your suppression accuracy is demonstrably better than anything a single-platform feature can deliver.
And honestly? Alert fatigue has been a documented problem since at least 2015. The fact that no standalone suppression product has won the market yet is worth sitting with. It might mean the problem isn't painful enough to drive tool switching. Or it might mean the integration complexity has always been too high for small teams to justify. The validation step above is specifically designed to answer that question before you invest four weeks.
Don't buy ads. Don't cold email a list. Go directly to the places where people are actively complaining about this problem.
Reply to r/sysadmin and r/devops outage threads. Not with a pitch, with a post showing before/after alert volume during a simulated provider outage and a repo link. DM the top commenters in the Azure outage thread. Post a Loom walkthrough in CNCF Slack #alerting. Submit to the Awesome-Prometheus list.
The timing matters. During the next major AWS or Azure outage, that's when you post. That's when people are feeling the pain in real time and actually receptive to a tool that solves it.
Community channel LTV/CAC is around 14:1 based on the numbers here. Cold email drops to 9:1. Start with community.