Day 1/100.
For the past two months, I’ve been building an open-source tool for on-call engineers in my spare time. When a Kubernetes alert fires, it automatically gathers context and sends a hypothesis about the "why" to Telegram, complete with evidence and a way to verify if the hypothesis is incorrect. By design, it doesn't touch anything in the cluster. Yesterday, I ran it on a real EKS cluster for the first time; the cost was 13 cents. I measured accuracy honestly: the local model got 5 out of 7 right on tricky scenarios, while the cloud model got 6 out of 6.
I’m asking for one of two things: if you use Kubernetes and handle on-call duties, I’d love a 25-minute chat about your most recent overnight incident. Alternatively, you could install and break it, it’s a single helm install command (link in the comments).
⭐ I’m not asking for star on GitHub, I’m asking for your any opinion.
Project: https://github.com/maxuver/sentinelops
Top comments (1)
Gathering context plus a falsifiable hypothesis, and never touching the cluster, is the right boundary for this — the moment an on-call bot can act, every false positive becomes an incident of its own. And the numbers are the interesting part: 5/7 on the local model versus 6/6 on the cloud one over seven scenarios is a small sample, but it's an honest one, published instead of a claim about accuracy. Was 13c for that first real run mostly embedding and context gathering, or mostly retries?
The part I'd push on is the verification path. You already send a way to mark a hypothesis wrong, which most tools skip — what I'd want to know is whether those markings come back into the eval set, because that's the only realistic way to grow past seven cases without hand-writing fixtures. And when three alerts fire at once at 03:00, does it correlate them into a single hypothesis, or send three and make you do the joining?