It's an incident management platform, similar to Pagerduty, Rootly or FireHydrant.
It's the first side project I've open sourced, and I've been hacking on it weekends and nights. Hoping to get a few companies to start using it to get some early feedback.
Using LLMs to classify noisy alerts is a really clever approach to tackling alert fatigue! Are you fine tuning your own model to differentiate between actionable and noisy alerts?
I'm also working on an open source incident management platform called Incidental (https://github.com/incidentalhq/incidental), slightly orthogonal to what you're doing, and it's great to see others addressing these on-call challenges.
Our tech stacks are quite similar too - I'm also using Python 3, FastAPI!
I wouldn’t say it’s particularly clever. It’s a fairly obvious idea to anyone who has worked with alerting through IMs. What it is, is /difficult/, because you really really need to avoid false positives. Probably lots of hard work involved. So kudos for making this work (if it works)!
We used to be customers of Mailgun, but last month moved over to SES. Not that there's anything wrong with Mailgun, SES's pricing is far cheaper (60K free emails if you're sending from an AWS instance), and deliverability is on par.
But SES is super basic. It's just an API, no fancy analytics.
So of course, I built a small web app that "wraps around" SES, and gives you some insight into what you're sending, some pretty graphs, and other stuff.
Mailgun is (was) great for setting up a quick regex to process incoming mail. Maybe I'm misusing it, but I point all my non-email domains there and let this regex forward everything to my main domain:
^(abuse@|hostmaster@|postmaster@|webmaster@).*
I'd gladly pay $.0008 per message x2 to cover both sides of that event because I have very little usage. By putting email receiving into a tier that costs over $400 per year they've priced me out of the service.
It's disappointing the way these companies are happy to have enthusiasts, hobbyists, and side projects light-housing their products for them at the start, but eventually switch to paid tiers that alienate those same types of early adopters. It feels like it happens with every single service I use.
Technically, yes. Practically, no. Mailgun has a checkbox to forward matched messages to another address, so the appeal was having something extremely easy, fast to configure, and reliable.
Building some type of custom endpoint for it is too much work for what it does. I already pay for email where I can set up unlimited domain aliases, so I'll just wait for my Mailgun email and switch back to aliases.
The incoming mail filtering was the only reason I decided to try Mailgun instead of Twilio or SES. I already have SES set up for transactional mail and my usage is so low they don't even bill me for it.
Really nicely executed! Love the clean and minimal design. However many of us would be unable use this in a corporate setting due to AWS credentials being shared with a third party service. I am sure if you packaged this service like Sendy (sendy.co) you could find a lot more corporate buy-in.
The problem with SES is that they ignore abuse reports. They even admit that they only block you if you have more than a given complaint rate. That is how gmail works, but for a bulk email service they really need to investigate every complaint.
That's why you need to investigate, rather than simply blocking the user. If set up correctly it should be mostly automated...ask the customer where the email address came from, then take appropriate further steps. SES does none of this, which is why they have this problem.
It's an incident management platform, similar to Pagerduty, Rootly or FireHydrant.
It's the first side project I've open sourced, and I've been hacking on it weekends and nights. Hoping to get a few companies to start using it to get some early feedback.