No two platforms fail the same way. RunLore learns yours.

It investigates your incidents, then opens a pull request with the cause it verified. What you merge becomes a memory tailor-made for your systems — your architecture, your constraints, the failures that keep coming back — and the next occurrence is answered from it in seconds.

Get Started View on GitHub

From alert to root cause — into memory you reviewed

What it actually produces

RunLore Slack notification — a verdict-first card headed 'CheckoutUiUnavailable — demo/orders-api-allow-payments-only': Action required, High confidence 80%, the cause traced to a CiliumNetworkPolicy that still denies checkout-ui to orders-api traffic and so fails the readiness probe, read-only suggested next steps naming the exact ingress rule to add, a What changed line and a Recurrence count, a footer of 6 model calls and 69,868 in / 9,603 out tokens, feedback buttons, and a link to the knowledge-base pull request it opened. — **An investigation — 6 model calls, 79,471 tokens.** The verdict first, then the evidence behind it — plus what it ruled out, what it still doesn’t know, and next steps it will *not* apply for you.

RunLore Slack notification showing an instant recall: a lightning-bolt Instant recall banner reading 'answered from your knowledge base, no investigation was run', the known cause carried over from the merged entry — a CiliumNetworkPolicy still denying checkout-ui to orders-api traffic — Medium confidence 55% after the verify pass re-checked it, an open question asking a human to confirm the recall still applies, a link to the entry, and a cost footer showing 2 model calls and 3,139 in / 2,721 out tokens. — **The same failure, next time — 2 model calls, 5,860 tokens. About 7% of the cost, in seconds.** Answered straight from the entry you merged: no investigation, no second pull request, and it cites the entry so you can check it. The two calls are the reranker and the adversarial verify pass — which is why the confidence reads lower than the stored entry’s. A recall is re-checked, not replayed.

Try it before you wire anything up

Watch RunLore investigate that incident and reach that root cause on your own machine — no Kubernetes, no LLM key, no network. You only need Go.

git clone https://github.com/Smana/runlore && cd runlore && hack/demo.sh

It replays a transcript recorded once against a live model through the real investigation loop — the same ReAct tool calls, verify pass and verdict renderer that run in production, over fake but realistic evidence. About a minute, most of it the Go build. See what it prints →

Knowledge you own

Every investigation opens a pull request in a Git repo you control. A human merges it. The result is portable markdown with full provenance — exportable, greppable, and yours if you stop using RunLore tomorrow.

Read-only by default

Reads your cluster, metrics, logs and network flows. Its only writes go to Git, via reviewed PRs — and it would rather say “I don’t know” than guess.

GitOps-native provenance

Turns “what changed?” into an exact Git answer — the rendered-manifest diff of the revisions Flux or Argo CD reconciled. That provenance is what makes the knowledge trustworthy.

Your models · one Go binary

A single self-hosted Go binary running in your cluster on your own model providers. Any OpenAI-compatible endpoint, or native Anthropic. No lock-in, your data. Point it at any MCP server for tools it doesn’t ship.

Its eval scorecard is published nightly, in full — per scenario, red or green.

Browse the docs

Getting Started

Deploy RunLore into a cluster and watch it react.

Concepts

The design, the learning loop, and the data sources.

Configuration

Configure the agent, its sources, and MCP.

Operations

Run, observe, troubleshoot, and upgrade.

Security

Read-only default, the action gate, the trust model.

Reference

Tools, benchmarks, and worked examples.