Agentic Sre

Srenix — self-healing for Kubernetes

Your cluster breaks at 3 AM. Srenix finds the fault, applies a policy-bounded fix, re-verifies, and posts one report to Slack — no dashboard, no pager, no 30 MB of YAML archaeology.

[](https://github.com/SRENIX-AI/agentic-sre/releases) [](LICENSE) [](https://goreportcard.com/report/github.com/SRENIX-AI/agentic-sre) [](https://srenix-ai.github.io/agentic-sre/)

One ~30 MB Go binary on a distroless base. 16 Kubernetes probes · 14 read-only analyzers · 30 cloud probes (AWS / GCP / Azure) · 5 auto-fixers — every fix policy-bounded, GitOps-aware, and re-verified after it runs. Apache-2.0.

Try it in 30 seconds (no cluster, no install, no RBAC)

git clone https://github.com/srenix-ai/agentic-sre.git
cd agentic-sre
go run ./cmd/srenix diagnose --snapshot examples/sample-cluster

• Ceph Storage:     🟢 HEALTHY    1 cluster(s): rook-ceph@rook-ceph OK (11.5% used)
• Cluster Nodes:    🟢 HEALTHY    All 4 nodes ready
• PostgreSQL:       🟢 HEALTHY    1 CNPG cluster(s): main@data (3/3 ready, primary=main-1)
• Storage Claims:   🟢 HEALTHY    All 3 PVCs bound

Diagnostics (3):
  🔎 Secret `billing/billing-svc-secrets` missing key `STRIPE_API_KEY` (referenced by
     Deployment/billing-svc in ns billing). Owning ExternalSecret: `billing/billing-svc-secrets`
     — add data/template entry exposing `STRIPE_API_KEY`, or remove the env reference if unused.
  🔎 ExternalSecret `billing/billing-svc-secrets` not Ready: error processing spec.data[0]
     (key: shared/billing/config), err: cannot find secret data for key: "stripe_api_key".
  🔎 ExternalSecret `billing/old-payment-gateway` not Ready: error processing spec.data[0]
     (key: shared/legacy/payments), err: vault path not found.

That's the headline: a precise diagnosis — which Secret, which key, which Deployment, which Vault path — from a read-only snapshot, on your laptop.

Then run it against your own cluster:

srenix snapshot capture --out ./my-cluster   # read-only; never modifies state
srenix diagnose --snapshot ./my-cluster      # diagnose offline
srenix diagnose --live                       # or straight against the live cluster

How it works

flowchart LR
    A[🔍 Detect16 K8s probes30 cloud probes] --> B[🧠 Diagnose14 analyzersroot cause + hint]
    B --> C{Recognized &policy-allowed?}
    C -->|yes| D[🔧 Remediate5 policy-bounded fixersGitOps-aware]
    C -->|no| E[📋 Precise remediationhint for a human]
    D --> F[✅ Re-verifyprobe again,prove the fix]
    F --> G[📣 ReportSlack / Alertmanager /OpenProject ticket]
    E --> G

Two ways to run it:

• Zero-trust offline mode — point it at a captured kubectl get … -o json snapshot. No install, no RBAC, no write permissions.
• In-cluster live mode — Helm-installed CronJob with two narrowly-scoped ClusterRoles (read-only + tightly-bounded write); posts to Slack on a schedule. Optional operator (AgenticSRE CRD) manages the whole deployment.

helm repo add srenix https://srenix-ai.github.io/agentic-sre
helm repo update
helm install srenix srenix/agentic-sre \
  --namespace agentic-sre --create-namespace \
  --set slackWebhookSecretName=srenix-slack-webhook

Why it's safe to let it fix things

Most "auto-remediation" tools ask you to trust an LLM with kubectl. Srenix doesn't:

• The hot path is LLM-free and deterministic. Detection, diagnosis, and fixing are pure Go — same input, same output, every time.
• Fixers only touch a closed catalog of known-safe patterns (stale Error pods, stuck Jobs on renamed Secret keys, stale-revision RS pods, terminal CertificateRequests, TLS secret mismatch). Never auto-applied: edits to Secrets, ConfigMaps, or generic CRDs.
• GitOps-aware: fixers skip anything managed by Argo/Flux/Helm rather than fight a reconcile loop; paused/suspended workloads are respected.
• Every fix is re-verified by re-running the probe, and reported either way.
• Narrow RBAC by construction: two ClusterRoles you can read in one sitting; the container is distroless (nonroot, no shell, no package manager).

Full catalog — every probe, analyzer, and fixer with symptom, root cause, and why the fix is safe: [docs/FAILUREMODES.md](docs/FAILUREMODES.md).

What's in the box

| Layer | Coverage | |---|---| | K8s probes (16) | Ceph, PostgreSQL (CNPG + Zalando), critical workloads, nodes, PVCs, external endpoints, node pressure, system DaemonSets, pending pods, CrashLoopBackOff, etcd, failed mounts, Kong, HPA, ArgoCD sync, Velero backups | | Analyzers (14) | Secret/key/ExternalSecret/image-pull/cert/TLS classes + drift: GitOps, workload-state, RBAC, config, capacity, security | | Cloud probes (30) | 10 each for AWS / GCP / Azure — RDS, EBS, EKS, IAM, ALB, ACM, KMS, S3, VPC and equivalents. Off by default, opt-in per provider, per-probe toggles | | Fixers (5) | Policy-bounded, GitOps-aware, re-verified. Opt-in for anything that mutates routing | | Investigator | On CRITICAL findings, a read-only Layer-2 deep-dive (DNS, HTTP, TLS, describe, events) attaches a one-line root cause to the alert | | Sinks | Slack (3-channel routing, per-severity repeat intervals), Alertmanager, OpenProject tickets via MCP, 6 Grafana dashboards |

Current version and the full shipped/planned matrix: [STATUS.md](STATUS.md) · What's next: [ROADMAP.md](ROADMAP.md)

OSS vs Enterprise

Everything above is Apache-2.0 and works standalone — probes, analyzers, fixers, cloud probes, deterministic investigator, Helm chart, operator.

Srenix Enterprise (commercial binary) adds the AI layer on the same safety contract: an LLM-backed Investigator, T0 narration → T1 fix proposals → T2 multi-step planning → T3 dual-approval break-glass runbooks — every action policy-bounded, Ed25519-signed, hash-chain audited — plus a curated Verified Signature Library regression-tested monthly. Details: [docs/SRENIXOVERVIEW.md](docs/SRENIXOVERVIEW.md) · Contact: srenix.ai/contact or info@srenix.ai.

Docs

| Start here | Deep dives | |---|---| | [SRENIXOVERVIEW.md](docs/SRENIXOVERVIEW.md) — the two-pager | [FAILUREMODES.md](docs/FAILUREMODES.md) — full fix catalog | | [SETUPGUIDE.md](docs/SETUPGUIDE.md) — install, Helm values, RBAC | [AITIERS.md](docs/AITIERS.md) — Layer-2 + T0–T3 spec | | [DEMOGUIDE.md](docs/DEMOGUIDE.md) — storyboarded failure scenarios | [DASHBOARDS.md](docs/DASHBOARDS.md) — 6 Grafana dashboards | | | [AIUSAGE.md](docs/AIUSAGE.md) — why the hot path is LLM-free |

Why I built this

Srenix came out of the same on-call loop I kept living: a 3 AM page, twenty minutes of kubectl archaeology, and a root cause that was almost always mundane — a stale Secret key, a stuck ExternalSecret, a cert that didn't renew. I wanted something that did that triage for me deterministically — with a fix catalog narrow enough that I'd actually trust it to run unattended — and posted one honest report instead of paging a human. That's Srenix. If it catches something for you, I'd genuinely like to hear about it in Discussions.

— Salil, maintainer

Community

Questions, war stories, and "it flagged something weird" reports: GitHub Discussions. Bugs and feature requests: Issues. If Srenix saved you a page, a ⭐ helps other on-call engineers find it.

License & security

[Apache License 2.0](LICENSE) for the engine and default signature library. The Verified Signature Library ships separately under a [commercial license](LICENSE-VERIFIED-LIBRARY.md). To report a vulnerability: security@srenix.ai ([SECURITY.md](SECURITY.md)).

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: SRENIX-AI
• Source: SRENIX-AI/agentic-sre
• License: Apache-2.0
• Homepage: https://srenix.ai

Install and usage instructions live in the source repository linked above.