How it works
From install to first catch, in an afternoon.
sudoSRE runs inside your cluster, builds a live model of your production, and uses it to catch the change that broke something, explain it, and roll it back with your approval.
01 Install
One Helm chart. Nothing else required.
The cluster agent runs in your cluster and starts building the Prod Map right away: which services call which, every change that lands, and what normal looks like for each service. It needs read access and nothing more.
$$ helm install sudosre sudosre/sudosre -n sudosresudoSREagentsudoSRE running on 6 nodes, read-onlymap42 services, 118 edges learned from trafficchangeswatching deploys, config, scaling, Helmbaselineslearning normal, ready in about an hour- No instrumentation changes
- Traffic, errors, and latency come from eBPF at the node level, so you do not add libraries or sidecars.
- Bring what you have
- Prometheus, Datadog, GitHub, Argo CD, and cloud audit logs plug in for extra detail. None of them is required.
02 Detect
Notice the bad change, not just the symptom.
For every change, sudoSRE compares the service and its callers against their own baselines for the minutes before and after. When errors or latency move well outside normal right after a change, it flags that change. It also catches crash loops, out-of-memory kills, and anomalies with no change attached.
sudoSREchangesudoSRE checkout-api v2.30.4 to v2.31.0 14:02:07errors0.4/s to 2.4/s (6.1x)p99412 ms to 1.3 s (3.2x)callersfrontend errors up 2.8xdetected1m 45s after the change- Before your alerts
- Detection does not depend on a threshold someone remembered to set. A regression is caught because it is abnormal for that service.
- Quiet by design
- Small absolute numbers and normal daily swings do not page anyone. A page needs a real regression with evidence.
03 Investigate
Show the cause, the evidence, and what was ruled out.
sudoSRE works through the Prod Map the way an SRE would: what changed, which services moved, what the dependencies were doing, and whether this has happened before. The finding names the likely cause and the commit when it is known, with every piece of evidence listed.
- Calibrated confidence
- Each finding carries a confidence level. When the evidence is thin, sudoSRE says it is not sure and lists what it checked.
- Your model
- Investigation runs on the model endpoint you choose, inside your environment.
04 Act
Roll back with one approval.
When a change is the likely cause, sudoSRE proposes the fix: roll back to the last good revision, restart, or scale. The proposal lands in Slack with the evidence beside it, and a person approves or rejects it.
- Off until you turn it on
- Actions are disabled by default and enabled one kind at a time.
- Policy you control
- Approval is required for every action unless your policy allows a specific kind to run outright. Every action is logged.
05 Verify
Confirm recovery, then remember it.
After an action, sudoSRE watches the service and its callers until they are back to baseline, and tells you when they are. The incident, its cause, and the fix are saved to Prod Map, so the next time the same thing happens it is recognized in seconds.
- Recovery is measured
- Resolved means the signals returned to normal, not that someone closed a ticket.
- Memory makes it faster
- Every resolved incident improves the next investigation on the same services.
Put sudoSRE in your cluster.
We are onboarding a small group of Kubernetes teams as design partners. Install takes one Helm chart, starts read-only, and is free during the partnership.