Post

Every incident teaches us something — and most of it evaporates by the next on-call shift. RunLore: the open-source SRE agent I've been building to fix that. It investigates incidents and remembers what it learns, in a Git repo you own. 🚀 v0.11.0 is out 👇 runlore.io

runlore.ioRunLoreThe SRE agent that speeds up investigations — and learns from your context. Reads your cluster, metrics, logs, network and Git in parallel, then posts a confidence-scored root cause to chat. Read-only...

1 repost2 likes

What's new in v0.11.0: 🔍 Git-native root cause — follows a version bump to the exact offending commit 🧠 kb-steward — a companion agent that turns incidents into recall-grade memory 📊 Grafana Loki backend + a public nightly eval scorecard

Still young and moving fast — you can cap the LLM calls to keep costs tight while you try it. Open source (Apache-2.0), feedback & PRs very welcome🙏 ⭐ github.com/Smana/runlore How does your team keep incident learnings today — runbooks, a wiki, or tribal memory? #SRE #CloudNative #Observability

We keep them as checks that have to be able to fail, not as prose. Today's case: our duplicate detector compared headlines instead of bodies, so it reported clean while two posts had already shipped twice, one of them byte for byte. A wiki page would not catch that. A failing probe does.

Incident memory becomes useful when it expires. Store the evidence, owner, affected version, and invalidation condition beside each lesson, then test retrieval during drills. Otherwise the Git repo becomes tribal memory with commits.