What inspired this? A number that reframed how I saw debugging: per ITIC's 2024 Hourly Cost of Downtime Survey, over 90% of mid-size and large enterprises say a single hour of downtime costs them more than $300,000 — and 41% put it between $1M and $5M. I'd been learning DevOps hands-on, and I kept losing hours to the same loop: describe the pod, tail the logs, scroll the events, diff the last rollout, guess, repeat. I assumed this was just my inexperience — that people doing this professionally had a cleaner process I hadn't learned yet. Then I talked to an SRE running production clusters about it. He described the exact same loop. The difference wasn't that he skipped steps, it's that he'd memorized enough failure modes to move through them faster. He was still manually reconstructing the story from scattered signals, every single incident, under pressure, at whatever hour it happened. That's when it clicked. This isn't a beginner problem that experience solves. It's a structural gap that experience only helps you survive. As a learner that hour is frustrating. In production, that same hour is revenue walking out the door. What problem was I solving? Kubernetes tells you what broke. It almost never tells you why, and never how to fix it. The fix itself is usually one command. The expensive part is reconstructing the story — logs here, events there, metrics somewhere else, and the actual cause three layers away from the symptom. It's not a knowledge problem, it's a time-to-context problem. Teams without dedicated SRE coverage feel it hardest, but as that conversation showed me, even the experts are paying it. So Kubric closes the whole loop instead of just one step: it detects the failure, correlates logs, events, metrics, and deploy history into one evidence-backed root cause, proposes a specific scoped fix, applies it on your approval, and then explains the failure mode so you don't relearn it next quarter. That last part is why I don't think of it as a troubleshooting tool — it hands you the reasoning, not just the data. How did the approach evolve? Significantly, and painfully. The first version was pull-based: the backend reached into the cluster and ran kubectl. It worked beautifully on my machine and was completely unshippable. No real team gives a SaaS inbound access to their control plane or lets it store their kubeconfig centrally — one breach would compromise every connected cluster. So I rewrote the entire data path. Now a lightweight agent runs inside your cluster, talks outbound only, and operates with least-privilege RBAC: read access, plus only the specific permissions needed for fixes you've approved. System namespaces are permanently off-limits. That rewrite cost weeks and shipped zero new features — but it's the difference between a demo and something you'd actually install in production. The second shift was on autonomy. I assumed people would want full auto-fix. They don't, not yet. So Approve mode is the default: nothing touches your cluster until you click. Where it stands This is Phase 1 — detect, diagnose, and one-click remediation for the most common failure modes (CrashLoop, OOMKilled, ImagePullBackOff, failed rollouts). Next up: pre-deploy risk assessment, Helm drift detection, Prometheus alert correlation, and team incident workflows. I'd really like your feedback. If you run Kubernetes in production, try the beta and tell me where the diagnosis gets it wrong, what fails most often in your clusters, and what you'd need to see before trusting it to apply a fix. Honest critique now is worth more to me than upvotes — it's what decides the next three months. Free for clusters under 10 nodes. One Helm command to install. I'll be in the comments all day

Maker

📌

3mo ago

Pazi

An AI agent that not only detects Kubernetes failures but diagnoses the root cause and fixes it - that's genuinely exciting for anyone running clusters. Congrats on the launch, Shashank!

@zvonimir_sabljic1Thanks Zvonimir, that means a lot coming from someone who's actually shipped agents people use. Checked out Pazi too, curious how you're handling trust on your end, since letting an agent take unprompted action on someone's business sounds like the same wall I hit with letting one touch a live cluster.

Kubric

AI agent that diagnoses and fixes Kubernetes failures

AI agent that diagnoses and fixes Kubernetes failures