Catch the bad deploy before it pages anyone.
sudoSRE is an AI SRE that runs inside your cluster. It watches every change and what it does to production, names the one that broke something, and rolls it back with your approval.
One Helm install · Read-only by default · Every action waits for your approval
- 14:02:07changecheckout-api v2.30.4 to v2.31.0, commit a41f9c2
- 14:03:52signalerrors 6.1x baseline, p99 412 ms to 1.3 s
- 14:03:58impactfrontend errors rising, ingress unaffected
- 14:04:20causecommit a41f9c2 set pool size 50 to 5. Confidence 92%
- 14:04:21actionrollback to v2.30.4, waiting for approval
- 14:06:40verifyerrors back to baseline. Resolved.
The gap
Most AI SREs start after the alert. By then, your customers have noticed.
01
They start when an alert fires.
If the alert was never written, or fires late, the investigation starts late. Plenty of bad deploys are first reported by a customer.
02
They need a full observability stack.
To investigate, they read from the monitoring you already pay for. Teams with partial coverage get partial answers.
03
They take a sales cycle to try.
Pricing sits behind a demo call and deployment is measured in weeks. A platform team of four cannot wait a quarter to find out if it works.
Prod Map
A live model of your production, built from inside the cluster.
Prod Map is the engine under sudoSRE. The cluster agent builds it from what actually happens: traffic between services, every change that lands, and how each service behaves before and after. Detection, investigation, and rollback all run on it.
Because it knows what changed and what normal looks like, it can tell you which change broke something, not just that something is broken.
01
Service graph
Which services call which, learned from live traffic. Nobody has to draw it or keep it current.
- services
- 42
- edges
- 118
02
Baselines
What normal looks like for every service: request rate, errors, latency, and resource use, by time of day.
- checkout errors
- 0.4 / s
- checkout p99
- 412 ms
03
Change timeline
Every deploy, config edit, scale event, and Helm release, captured where it lands: in the cluster.
- changes today
- 37
- last
- checkout v2.31.0
04
Incident memory
What broke before, what caused it, and what fixed it. A repeat is recognized in seconds.
- incidents kept
- 128
- seen before
- redis pool, x3
Sample data.
The loop
From bad change to verified recovery, in minutes.
01
Detect
Compares every service against its own baseline, before and after each change.
- service
- checkout-api
- errors
- 6.1x baseline
- after change
- 1m 45s
02
Investigate
Works through the Prod Map and shows every piece of evidence it used.
- cause
- commit a41f9c2
- ruled out
- redis, payments
- confidence
- 92%
03
Act
Proposes a rollback, restart, or scale. A person approves it in Slack.
- action
- rollback
- to
- v2.30.4
- approved by
- @maya
04
Verify
Watches until the service is back to normal, then records what happened.
- errors
- baseline
- time to recover
- 4m 33s
- saved to
- memory
Resolved
Sample data.
Data sources
Sees changes where they land: in production.
The cluster agent sees every deploy, config change, and rollout directly, so sudoSRE works on day one with nothing else connected. Your other tools add detail, like the commit behind an image, but none of them is required.
Core
One Helm install. Required.- Cluster agenttraffic between services, via eBPF
- Kubernetesrollouts, config, scaling, events
- Helmrelease history
Optional
Adds detail. Never required.- GitHub, GitLabthe commit and diff behind a deploy
- Argo CD, Fluxsync history
- Prometheus, Datadogmetrics you already collect
- AWS, GCP, Azurecloud audit logs
Naming a tool here describes what sudoSRE reads from, not a partnership.
Guardrails and security
Read-only until you say otherwise.
Watching production needs read access and nothing more. Letting sudoSRE act is a separate decision, made one action at a time.
- Runs in your cluster
- sudoSRE installs with one Helm chart into your own cluster. There is no hosted copy of your environment.
- Telemetry stays put
- Prod Map keeps a model of your services and their signals, not a copy of your logs, and it never leaves your infrastructure.
- Bring your own model
- Point it at the model endpoint you already trust, with your own key, in your own account.
- Read-only by default
- The agent can watch but not change anything until you enable actions. Each action kind is turned on separately.
- A person approves every action
- Rollbacks, restarts, and scaling wait for approval in Slack unless your policy allows them outright. Every action is logged.
FAQ
Questions teams ask first.
Short answers. If yours is not here, ask when you request access.
What is sudoSRE?
sudoSRE is an AI SRE for teams running Kubernetes. An agent in your cluster watches every change and how each service behaves before and after it. When a change breaks something, sudoSRE names the change, shows the evidence, and proposes a rollback that a person approves.
What is Prod Map?
Prod Map is the engine under sudoSRE: a live model of your production with four layers. A service graph learned from traffic, a baseline of normal behavior for every service, a timeline of every change, and a memory of past incidents and what fixed them.
Do I need other monitoring or paging tools?
No. The cluster agent collects traffic, errors, latency, and changes itself, and sudoSRE can send its own alerts to your team chat. If you already run other monitoring, source control, or deployment tools, sudoSRE can read them for extra detail, such as the commit behind a deploy.
How does it detect a bad deploy?
For every change, sudoSRE compares the service and its callers against their own baselines for the minutes before and after. When error rate or latency moves well outside normal right after a change, it flags the change and starts an investigation, usually within two minutes.
How do I know the answer is right?
Every finding lists the evidence it used, what it ruled out, and a confidence level. When the evidence is thin, sudoSRE says it is not sure instead of guessing. During onboarding we replay your past incidents through it so you can see how often it would have been right.
Can sudoSRE change production?
Not by default. The agent is read-only until you enable actions, and each action kind is enabled separately. Rollbacks, restarts, and scaling wait for a person to approve them in Slack unless your policy allows them outright. Every action is logged.
What does sudoSRE cost?
sudoSRE is free for design partners while it is pre-release. Self-serve pricing will be published at launch, so a team can install it and try it without a sales call.
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.