Feature
The fix is not done until it is checked.
Srenix runs inside your cluster, and no telemetry ever leaves it. After every fix it re-runs the same diagnosis: live state re-checked at the moment of applying, the finding verified as actually cleared afterwards, and a fix that is later rolled back counted as a failure. The other three feature pages: detect, remediate and audit trail.
The audience problem
The fix went in. Did it work?
The patch landed, the pod restarted, the dashboard is green — and the on-call closes the ticket on the hope that it held. A fix that does not hold surfaces later, in a reopened alert, a roll-back someone does at the next incident, or a deploy that is undone without a note. The gap between “the change was applied” and “the problem is gone” is where fixes quietly fail — and no tool in the loop is counting the failures.
What it replaces
The ticket closed on “the fix probably worked”.
It replaces the close of the loop: the re-check after the change and the record of what the re-check found. The diagnosis arrives from the probes and analyzers — the full story is on the detect page — and the change arrives from the fixers, each bounded to its one case — the remediate page. What is left is the question nobody else answers: is the problem actually gone, and if it comes back, was the fix a failure?
The re-diagnosis loop
Every fix is re-checked before it is called a fix.
Verification is not a status flag. It is the diagnosis, run again:
- Live state re-checked at the moment of applying — the cluster is read again as the change lands, so the apply happens against the state the fix assumes, not the one the diagnosis first saw.
- The finding verified as actually cleared afterwards — the same probes and analyzers that raised the finding run again, and the fix counts only when the finding does not come back.
- The breaker keeps watching — verification does not stop at the moment of the clear; the watch that found the problem keeps running over the fix.
Reverted counts as failed
A fix someone rolls back is not a success.
Success is counted against three outcomes: the finding cleared, the finding still present, and the finding cleared and then rolled back. A change that lands and is reverted later is a failure, and a failed fix stops that kind of fix running on its own until a person looks. No “the fix probably worked” — it re-checks and closes the loop, and the counting is there when the question comes up at the post-mortem.
Setup and integrations
One chart per cluster. Your stack stays your stack.
Verification ships in the same Helm chart as detection and remediation — one chart per cluster, Kubernetes 1.27+ on EKS, GKE, AKS, k3s, RKE2 and OpenShift. It runs on the same probes the diagnosis ran on, and the model endpoint is yours, any OpenAI-compatible one, including in-cluster vLLM. A verified outcome reaches Slack, Alertmanager and OpenProject with the rest of the loop — the full list is on the integrations page.
Pricing policy
Flat price per cluster. No per-verify billing.
Enterprise pricing is a flat price per cluster per month, quote on request — the numbers are on the pricing page. A re-check costs nothing extra, and if a licence lapses Srenix falls back to the core engine and keeps finding and explaining problems.
Honest limitations
Beta, with pilots in progress. And the loop has edges.
Srenix is in beta with pilots in progress — features and pricing may change before the wider release. No certifications are claimed. The boundaries of what the re-check can say:
- Verification covers the fixes Srenix made — the cases on the remediate page. A fix a person made by hand is not a fix Srenix verified.
- A re-check is a read. It confirms the finding is gone; it does not change anything to prove it.
- It cannot verify against an offline snapshot. A snapshot is for diagnosis; the re-check needs a live cluster.
- “The finding did not come back” is a statement about the watch that found it. A failure no probe watches for is not something verification can catch.
What exactly does it re-check?
The same diagnosis. Live state is re-checked at the moment of applying, then the finding is verified as actually cleared afterwards by the probes and analyzers that raised it, and the breaker keeps watching after the clear. None of these replace the others.
What counts as a failed fix?
A fix that is later reverted. The denominator is cleared, still present and reverted — landing a change and having someone roll it back later is not a success. A failed fix stops that kind of fix running on its own until a person looks.
Does verification run without the auto-merge path?
Yes. The re-check runs after every fix Srenix makes — whether it landed on a click or through the path that acts alone, which is off by default. Verification is a read — it changes nothing.
The field
Where this sits among the other tools.
How Srenix compares with NeuBird, Resolve AI, Ciroos and OpenSRE is on the compare page; the 2026 field is surveyed in Best AI SRE tools for Kubernetes in 2026. The rest of the loop: detect, remediate and audit trail.
See it close the loop on your cluster.
Install takes five minutes and changes nothing until you let it. We will walk a real incident on your stack with you, re-check included.
Or run the read-only snapshot first — no install, no RBAC: srenix diagnose --snapshot <dir>.