keep

ke a swiss army knife for alerts - anything from collecting, enriching, correlating, and automating. We have over 90 integrations: anything from alerts, topology (CMDB), ticketing, databases, etc., a GitHub-Action-like interface for your monitoring stack (we did a Show HN for it here: https://news.ycombinator.com/item?id=37381268) triggers manually, cron, alert or incident-based, a smart correlation layer, where we use LLMs or pre-configured rules to correlate alerts into incidents (imagine “DB is down” and plenty of 5XX from other services), opinionated or customized deduplication rules to view only the alerts that matter, extraction and mapping capabilities to extract/add missing bits of information to alerts, a single pane of glass to see and manage everything in one place and batteries-included LLM: chat with your observability data Tools like BigPanda, Moogsoft, Splunk ITSI, or Datadog Event Management treat AIOps as a side quest – trying to vendor-lock or deploy AIOps for huge enterprises only while we build a tool that can serve organizations of any size. We are completely open-source (MIT license), and we monetize on a SaaS-managed version and enterprise features: SSO, RBAC, Auditing, 24/7 support, longer retention, and private deployments. We are excited to share what we’ve been working on for the last year and would love to hear your feedback and opinions! Hosted Demo: https://playground.keephq.dev Open Source: https://github.com/keephq/keep Landing Page: https://keephq.dev

having more than one tool (and for example, according to Grafana’s 2023 observability survey, 52% of the companies uses more than 6 observability tools https://grafana.com/observability-survey-2023/). So we that in mind, we rebuilt Keep with a simple mindset: (1) Integrate with every tool that triggers alerts - it can be either pushing alerts to Keep via webhooks or routing policies or Keep to pull alerts via the tools API. (2) Create a simple abstraction layer to run workflows on top of these alerts. (3) Maintain a great developer experience - open source, API-first, workflows as code and generally having a developer mindset while building Keep. During the time we rebuilt Keep, Datadog released their workflow automation tool (https://docs.datadoghq.com/service_management/workflows/) which led us to the understanding that's exactly what we solve - but for everyone who uses tools other than Datadog. A short demo of Keep with a simple use case: https://www.youtube.com/watch?v=FPMRCZM8ZYg You can try it yourself by signing into https://platform.keephq.dev Like always - we invite you to try Keep and we are eager to hear any feedback.

emo: https://youtu.be/ZX5mrnMRCwU Why we built this: - We needed an easy way to let Keep (https://github.com/keephq/keep) customers behind closed networks monitor their Keep instance - We needed an easy & quick way to setup monitoring for our cronjobs - We wanted to give people with complex networking situations (e.g. behind a firewall) an easy way to monitor their services/processes The beta version lets you: - Create 5 endpoints for free - Configure the endpoint and the payload to be sent when the subdomain is not hit - See the visits (every HTTP GET request to your subdomain) and requests (every HTTP POST sent to your configured endpoint) - Secret header (x-peeng-secret) that confirms requests are made by you What’s next: - A status page that displays your subdomains and their health together with embeddable status blocks that allow you to display the status of an endpoint in your web page (you can also send query params when sending the GET requests that will be included) - Rest API (for subdomain creation, beats retrieval, etc., imagine curl -X POST peeng.sh/subdomain -H API_KEY —json {”subdomain”: “hn”, “endpoint”: “https://xn--ivg, “payload”: {…}}) - Hierarchy-based subdomains that allow you to create a nested heartbeat solution (i.e. dynamically create a heartbeat subdomain under x.peeng.sh → y.x.peeng.sh, z.x.peeng.sh) This is still very early, so we’d love to hear your feedback and opinions. We’re open to any feature request, so just reach out via Intercom :)

hat keep you monitored. So, for example, if you create a .keep/db-timeout.yaml and open a PR, the bot will comment on the PR with the actual alert you can deploy to your tool. # The alert text in plain English alert: | Alert when the connections to the database are slower than 5 seconds for more than 5 minutes provider: grafana You can Install the bot and connect your providers via https://platform.keephq.dev (after login, you'll start the installation flow) or just clone the repository and use docker-compose to start the web app and the installation flow. Demo Video - https://www.loom.com/share/23541a03944c4dca99b0504a1753d1b4

Alerts from multiple data sources for added context and insights. 3. Freedom from vendor lock-in, making it easier to switch to a different observability tool if needed. Some of the features we plan to add in the future include: - Integration with CI/CD processes to simplify alerts maintenance and testing. - Scoring system to assess the alert's urgency and provide relevant information. - Slack integration to keep track of alerts over time. - More providers, conditions, and other enhancements. We invite you to give Keep a try (https://github.com/keephq/keep) and share your thoughts with us. Your feedback will help us make Keep the best it can be.