hckrnws

Product looks solid but please stop it with that dark mode joke. I'm technical within all definitions you could possibly come up with but white-on-dark is just unbearable for my eyes.

Thanks! what would you expect from dark mode?

There are a lot of studies that proof that darkmode during day is straining eyes much more. In the night dark mode is better. But most of the "day-to-day" user are working during day.

are you referring to the product or the toggle in our marketing website?

the toggle on the website

https://x.com/elonmusk/status/1863365002109108655?s=48&t=r-0... :D

Congratz on the launch! is it relevant for early-stage products with small teams or is it an overkill? we're just kicking our observability tools (Vercel, AWS - ECS infra)

it's definitely relevant for early-stage products who deeply care about realiability. are you already handling some amount of alerts today? there's a bunch of stuff you can do with workflows to automate processes and help your users.

we do integrate with AWS Cloudwatch but not yet with Vercel's observability, but can add that if you want to give it try

We will check the Cloudwatch integration, thanks!

Contrats on the launch, this looks pretty good, interesting, useful, and especially for such a stage, integrated with a ton of things!

If you're taking feature requests, it would be pretty cool if you added support for Nomad[1] as an orchestrator too.

1 - https://nomadproject.io/

Deployment with Nomad should be pretty straightforward following https://github.com/keephq/keep/blob/main/docker-compose.yml or https://github.com/keephq/helm-charts

Interesting! What type of integration do you imagine?

Similar to the other orchestrators, doing restarts and deployments and maybe even scale outs.

I guess you could use the existing SSH functionality to do restarts and deployments.

Congrats on launching.

Congrats on the launch!

TIL that BigPanda and Moogsoft solve the same problems which you are trying to solve :)

Would have loved to see SigNoz also in the list of supported integrations

providers are usually driven by the community! happy to collaborate on that provider if you’d like.

Small typo on your "Mapping" page "Enirch alerts with more data from Topology, CSV, JSON and YAMLs"

thank you for that! fixed in https://github.com/keephq/keep/issues/2681

Damn, answering feedback with a pr link is fireeee

trying to keep that high pace!

I love me some worfklows. Please keep this typo…pretty please? :)

haha! gotta fix those for my ocd: https://github.com/keephq/keep/pull/2684 ^^'

At least it will be preserved in the PR title.

What's an actual use case for this?

for small teams we mostly see workflow automation on their alerts, for bigger teams it’s also unified API for alerts from many tools and single pane of glass for alerts

ok but what problem does this solve that I can't solve with Slack notifs

With slack you lose history and context. Also collaboration is harder. Also if you have some processes/workflows you want to maintain in some GitHub repo and manage as code/gitops, you can’t do it with Slack. Deduplicating alerts is also a thing. Basically it’s a different use case

Thanks for the clarification. Would you be able to provide a concrete example for this product’s differentiated use case

Np! Company A have 4 monitoring tools and 2 IRM’s. Few dozens of alerts per day. They use Keep to streamline their ticketing routing, enriching the ticket from a prod db, some if/else logic. Every month they do some research on the alerts they had last month with slice and dice per team/app/etc.

Company B, with big operations group, use Keep as single pane of glass where NOC dispatch incidents and sync context from every system.

Thanks. The first example painted a better picture

product is slick, congrats on building this guys!

thanks! <3

Looks great! What about some Zapier support?

$1/alert/month???

actually, it’s 100 workflows, 20 providers and 10 users. important to note that it’s per deduplicated alert and not every event ingested by keep. what got you surprised about this pricing model?

I work in e-commerce at a large marketplace.

In surprised because 500 deduplicated alerts requiring human attention is a normal day for my company. If something goes really wrong it'd start to get very expensive.

one of our goals is to help you better manage those alerts and reduce the total number. I would have loved to hear more about those 500 alerts use case, im sure checking up Keep would be a super interested use case

how big is this problem? do they recognise it first hand

actually alert fatigue started from healthcare initially where doctors become desensitized to safety alerts, and as a result ignore or fail to respond appropriately to such warnings - it is the same problem in tech companies where you get all these muted Slack channels. It’s a problem almost every company faces at some point of its life

It looks quite interesting, that's said, I wish people would stop calling projects open source when they aren't and most if not all projects here in Show/Launch are open core - same with Keep. You have a proprietary license in the project, with parts of the code with an open source license.

Companies adopt different strategies when building Open Core products. Some aim to keep the Open Source portion minimal, reserving the most valuable features for their paid versions. At Keep, we chose the opposite path—moving nearly everything into Open Source. Our philosophy is that most users should be able to fully benefit from the Open Source version.

While I understand (and share) the caution around licenses, I don’t think this concern applies to Keep. With 99% of our codebase under the MIT license, it’s a far cry from just having "parts of the code with an open source license."

I recommend running Keep locally and comparing the Open Source version to the playground where full version is running. You might find it challenging to spot the differences.

I also reccomend comparing Keep Open Source to BigPanda and Moogsoft. It may be surprising how much of it Keep OSS, real MIT-licensed Keep has.

Sorry, maybe I sounded diminishing in my post, and I didn't want that. However, the business is still open-core, even if 99% of it is open source. That 1% can taint the project more and more in the future (and MIT obviously allows for the open-source part to go fully proprietary in the future).

1% of cyanide compared to your body weight is still lethal.

P.S. I played a bit last night and I will for sure give it a try (I'm an idealist but still pragmatic and I hope people at Keep are similar)

Regarding the "1% of cyanide" comment, I’d like to share another perspective :)

Almost every tech company has private code—typically stored in private repositories. When working on Keep, we faced a decision: should we place certain code in the EE folder under a different license or keep it in a private repo, only sharing it with a small group of enterprise customers who explicitly requested it?

We chose to put that code on GitHub.

Ironically, putting more code in the GitHub repo made it appear "less open source," even though we could have simply hidden it, making the repo look like "clean OSS" as multiple companies do. For example, those who put their products without Web UI to the open source, build UI privately and serve the "full" version in the cloud.

Fair arguments and criticism. That doesn't make them better at all, I think we can agree on that (and as you mentioned the Web UI situation, yeah, that makes them way worse in gran total).

I wish you all good luck, the product looks good, I hope you monetize it and I hope no big corp forks it and makes some closed source alternative (because MIT license does allow exactly that).

Ok, I've taken "open source" out of the title now. The definitional argument here isn't really on topic.

Yo! I can say that most of our users are open source users. We are community-driven, and like 95% of the features are open source. It’s true that we need something to monetize on but I really feel that we are an open source company.

Kudos. I appreciate the desire to be open source and the need to monetize (and I don't have a golden solution to it, so I would probably do something similar), but I just wish that people clearly define that they are open core because there are a lot of amazing open source projects out there, and it wouldn't be fair to them to be called open source when they aren't.

thanks for the clarification, sorry if it sounded like we’re thinking your comment is not legitimate. It absolutely makes sense.