Keep AIOps in 2026: Is the Open Source Platform Still Alive?

Keep (keephq/keep) is an open source alert management and AIOps platform: it collects alerts from monitoring tools, deduplicates them, correlates them into incidents, and runs YAML workflows that open tickets, notify people or call other tools. Elastic announced on May 7, 2025 that it was acquiring Keep, said Keep would "remain open source", and completed the deal on May 21, 2025. When we checked on 2026-10-21, the project was still shipping but slowly: a maintainer describes a "community-maintained" phase, the latest release was v0.54.3 (2026-09-09), and the hosted Keep Cloud address served a TLS certificate that expired on 2026-06-17. The self-hosted MIT core is still published; the AI correlation feature is not part of it.

Arvo AI builds Aurora SRE, an open source investigation agent that can sit behind an alert platform like Keep. We did not install Keep for this page. Every Keep fact below comes from its repo, docs and website, or from checks we ran against them on 2026-10-21, and is linked. The lab results come from our own benchmark, where Arvo wrote the scenarios.

What is Keep (keephq) and what does it do?

Keep's README calls it "The open-source AIOps and alert management platform" and lists a single pane of glass, deduplication, enrichment, filtering and correlation, bi-directional integrations, workflows and dashboards. Elastic's acquisition post describes it the same way and says it dedupes, correlates and prioritizes events "to reduce noise and automate root cause analysis". The Keep homepage claims "110+ Providers": monitoring tools that send or are polled for alerts, ticketing and paging tools it writes to, and LLM providers.

Keep describes itself as an "intelligent layer before the IRM" on its comparison page: it reduces and groups alerts before they reach PagerDuty or Opsgenie, and it positions itself as an alternative to BigPanda and Moogsoft.

Is Keep still maintained after the Elastic acquisition?

Yes, at a much lower pace than in 2025. On 2025-11-22 a user asked on GitHub whether the project was still alive after being acquired by Elastic. Maintainer Shahar Glazner (shahargl) answered the same day:

Keep as an OSS project is now in a "community-maintained" phase where we (me and @talboren) review PR's from the community and merge them. We also solve bugs discussed on Keep's Slack community.

The numbers we pulled from the GitHub API on 2026-10-21 match that description:

Of the 140 commits on main in 2026, 93 have a "fix" prefix and most come from outside contributors; all 139 pull requests merged in 2026 were merged by one of the two maintainers. The endpoint results are one check from one network at one time; a 525 can be a temporary origin fault, so retest before you rely on it. Elastic's 10-K for its 2025 fiscal year says it acquired all of Keep Alerting Ltd. on May 21, 2025, and its announcement said "Keep will integrate with Elasticsearch and Kibana and remain open source"; the repo is still MIT outside one directory, so that part holds. We found no current statement from Elastic or Keep on whether Keep Cloud or the Enterprise plans are still sold. The pricing page still lists them under a 2025 copyright, and the status page it links lists no public monitors. If you need the AI correlation tier, ask Elastic or Keep directly before planning on it.

What this means in practice: the self-hosted code is published, still gets bug fixes and releases, and is maintained by two people reviewing community pull requests. That can work for a team that can patch Python and Next.js itself. A team that needs a vendor to answer a security report should get that commitment in writing first.

Is Keep open source and free?

The LICENSE puts everything under MIT except an ee/ directory, which has its own license; on 2026-10-21 that directory held only an identity manager module. Self-hosting is free. The pricing page lists Startup at "$0 / month", Growth at "$199 / month" and "Enterprise + AI" at "Prices fitting your needs"; "AIOps Alert Correlation", SAML/SSO and RBAC appear only in the Enterprise column. Given the Cloud endpoint failures above, treat those plans as unconfirmed.

Does Keep do root cause analysis, or only correlation?

Both, in different parts of the product. Keep's correlation works on alerts: their fields, fingerprints, timing and, if you load it, a service topology. On top of that, the AI incident assistant passes the incident's alerts, description and topology to an LLM, and Keep's provider methods page says it can call methods on connected tools on request (its examples fetch Datadog traces, metrics and logs; the Opsgenie provider exposes close_alert) and "Chains multiple methods for comprehensive investigation". A self-hosted workflow can also run shell commands through the Bash provider. The docs mark the assistant experimental in the open source edition, describe it as a chat the on-call engineer drives, and do not describe it starting an investigation on its own when an alert arrives. We did not run it.

That is the difference with an investigation agent: it starts on the alert without being asked, queries the systems behind it (pods, events, Services, logs, recent changes), and returns a cause with the evidence. The lab shows why that step cannot come from the alert fields alone.

What does an alert tell you about the root cause? Evidence from 19 injected faults

In our benchmark, each of 19 scenarios breaks one thing in a small app on a 3-node kind v0.33.0 cluster running Kubernetes v1.37.0 (scenario 12 breaks two). Each scenario comes with one alert, written by us in Prometheus style and given to the agents as text. There are only four alert names across the 19: KubePodCrashLooping (9 scenarios), HighErrorRate (5), KubeDeploymentRolloutStuck (4) and KubePodNotReady (1). Two pairs of scenarios carry the same alert, word for word, with different causes:

To an alert platform, each pair is the same alert: same name, same labels, same text. Deduplication, rules and an ML correlator all work from those fields, and nothing in them separates a wrong port from a NetworkPolicy. The agents separated them by reading the cluster. In all 16 runs on these four scenarios, both agents named the actual cause. The four partial grades were for something else: three runs on scenario 11 did not rule out a worker whose logs were noisy but harmless, and HolmesGPT's first run on 18 offered deploying a postgres Service as one of two fixes without noting that the api does not use one.

Aurora's first run on scenario 13 (2026-10-02, 25 tool calls, 202 seconds, $0.69 of model cost) found it by checking the policy against the pod labels:

The root cause was a NetworkPolicy named redis in the shop namespace, created at 2026-10-02T20:23:54Z, which restricts ingress to redis:6379 to pods labeled app=worker only [20, 22].

On scenario 11, with the identical alert, its first run reported that the Service's spec.ports[0].targetPort "was set to 9090, while the api Deployment's containers only expose and listen on port 8080 [17, 13]". The bracketed numbers point to the tool calls that produced the evidence. The fixes are in the runbooks: NetworkPolicy blocking traffic, Service targetPort mismatch, ResourceQuota blocking a rollout and pod stuck on an init container.

K8sGPT, the third tool in the benchmark, takes no alert: k8sgpt analyze lists objects its analyzers flag. On scenarios 11 and 13 it printed "No problems detected" in all four runs, because every object looked healthy. It is a scanner, so we do not score it as a peer of the two agents.

The limit runs the other way too. In scenario 12 the alert covers an OOMKilled worker while, separately, the frontend Service selects no pods. The scenario raises no alert for the second fault, so an alert platform has nothing to group it with. Both agents found the OOM in both runs and missed the frontend, and Aurora wrote that the other workloads "remained healthy and unaffected" on pod status alone. The checks it skipped are in a second fault the alert does not cover.

Totals and caveats

A judge model graded every answer against the scenario's required findings. A person at Arvo read all 38 Aurora grades and changed none. The 76 HolmesGPT and K8sGPT grades are judge-model only: a second model re-read all 76 and agreed, a third pass graded them from scratch and agreed on all 38 HolmesGPT verdicts while disputing 6 K8sGPT labels, and a blinded regrade matched 38 of 38 Aurora, 37 of 38 HolmesGPT and 36 of 38 K8sGPT verdicts. Aurora ran on 2026-10-02 (commit 87d22baf), HolmesGPT and K8sGPT on 2026-10-15 and 16, on the same cluster and faults. Aurora and HolmesGPT used the same model (Claude Sonnet 5 on Bedrock); K8sGPT used Sonnet 4.5. The prompts added different one-line instructions after the alert text, and all three got the same admin kubeconfig behind their own guards. HolmesGPT is about 3x faster at the median. Full method, every trace and the misses: Aurora lab report and Aurora vs HolmesGPT vs K8sGPT.

Keep vs Aurora: what each one does

Pick Keep when the problem is volume: alerts from many monitors, duplicates, and routing rules you want in YAML. Pick an investigation agent when the alerts already reach the right person and the time goes into working out why. If you are choosing between investigation agents, the open source AI SRE comparison covers HolmesGPT and K8sGPT; for the alert-noise side, see automated alert noise reduction.

Can Keep and Aurora work together?

Yes, through a paging tool both already support. Aurora has no Keep connector (we checked the repo on 2026-10-21), and Keep has no Aurora provider. Keep's PagerDuty provider can create incidents from a workflow, and its Opsgenie provider can create alerts. Aurora takes PagerDuty webhooks (incident.triggered) and Opsgenie or JSM Operations webhooks (alert create events), and starts a background investigation for each one. So the chain is: monitors send to Keep, a Keep workflow on the correlated incident creates one PagerDuty incident or Opsgenie alert, and Aurora investigates that one incident instead of every raw alert. If you turn on RCA notes and give it a token with write access, Aurora also posts the root cause back to the PagerDuty incident as a note.

We have not run this chain end to end. Test it with one workflow and one service before you route production through it, and if you depend on Keep, have a plan for maintaining your own fork.

Which open source AIOps tools support bring-your-own-model?

Among the tools on this page: Keep's AI workflow steps use the provider you configure, including local Ollama, Llama.cpp or vLLM; its AI correlation does not, since it runs on Keep's service. Aurora runs on the model you choose, including Ollama for air-gapped installs. HolmesGPT and K8sGPT also take your own provider. One caution from our lab: every result above used Claude models on Bedrock, and accuracy on a local model is untested. For the wider field, including Coroot, see AIOps platforms with root cause analysis and top AI SRE tools in 2026.

Is Keep a cheaper alternative to BigPanda?

Keep positions itself as one, and its free and $199 tiers are far below enterprise AIOps pricing. Two things narrow that. The AI correlation that compares with BigPanda's is in the Enterprise tier only, and Keep Cloud did not load when we checked on 2026-10-21. The self-hosted rule and topology correlation is free and works without a vendor. For the full field, see BigPanda alternatives.

How to test any of this yourself

The scenarios, alerts and grading rubric are in Arvo-AI/aurora-lab. Break a scenario on a local kind cluster, send its alert through Keep or straight to an agent, and grade the answer against must_identify in the scenario's scenario.yaml. Try scenarios 11 and 13 back to back: same alert, different fix. For a single failure on your own cluster, paste the symptoms into /diagnose.

Verified 2026-10-21: Keep's GitHub repo, LICENSE, releases, commit and pull request counts and issue 5451 (GitHub API); Keep docs pages and pricing page as linked; Keep Cloud and API endpoints (curl -v and openssl s_client, 16:26 UTC); Elastic's acquisition post and its fiscal 2025 10-K; Aurora's README, connector docs and webhook routes at commit 6018891. Lab numbers come from results.json.

Aurora is on GitHub under Apache 2.0, or book a demo to run it behind your own alerts.