Use case
Runa and incidents, on Kubernetes
Investigate a Kubernetes incident with an AI agent.
A workload starts crash-looping. This page follows what happens next in Subnomic: what Runa reads, how it decides what to read next, and the three places a fix can come from, each of them bounded by permissions and guardrails.
An illustrative example. The workload, versions and figures below are made up to show the steps. They are not a recorded incident, a transcript or a benchmark.
Before the incident
What has to be in place.
- The Subnomic agent running in the cluster. It dials out; the cluster opens no port.
- An agent access for Runa that can read the cluster (kube.read, resource.read), limited to the clusters it should see.
- An alert rule that opens incidents, and AI turned on for the workspace. Incidents and proposed fixes come with Team.
- Guardrails for the changes you want a person to see first, such as anything in the production namespace.
Step by step
From the first restart to the postmortem.
The alert opens an incident
An unhealthy-resource rule fires and opens an incident with a timeline, a commander and a Recent changes panel. If nobody acknowledges it, it escalates to the on-call.
A first triage is written
In the background, a read-only investigation searches operational memory for earlier occurrences and the activity log for what changed, and writes a summary, a likely cause and next steps onto the timeline.
Somebody asks Runa
Mention the cluster or the deployment and ask why it restarts. Runa starts from what was mentioned and calls tools through its access: a crash-loop report, events, the previous container’s logs.
It decides what to read next
There is no fixed playbook. A log line about a missing variable sends it to the rollout history and recent changes; an OOM kill would have sent it to the memory limits. Each call is shown with its arguments.
A fix is proposed, then judged
Runa names the change and why. Whether it runs, and who has to say yes first, depends on where it is made, as the next section explains.
The record stays
Every change lands in the activity log, attributed to whoever made it. When the incident is resolved, a postmortem is drafted from the same timeline.
Where a fix runs
Planning is free. Acting is not.
Runa can reason about any change, but it can only make the ones its access allows, and every one passes the guardrails. In this example the fix is a rollback to 2.7.3; there are three ways it can happen.
| Where | Who acts | What bounds it |
|---|---|---|
| The incident’s Remediate panel | A person picks restart, scale or set-image on one workload | Needs resource.write; only while the incident is open; a guardrail that requires approval refuses it, and the person’s click cannot override that |
| Runa’s chat | Runa calls the tool, in a conversation a person is having | Only with an access that holds resource.write. There is no per-call confirmation in chat: a guardrail is what makes a change stop |
| A supervised Runa run | Runa works through a plan with checks, and parks each action | Every action waits for a person; destructive ones need a typed confirmation. A run cannot change an image at all, so this rollback stays with a person |
Runs are off until a workspace turns them on, and read-only by default. Over MCP, your own agent can use the same read tools; a change it is allowed to make runs without a prompt, and one a guardrail would hold is refused.
Limits
What it will not do.
- Reach a cluster or target its access does not name, or exceed the permissions of the person who created that access.
- Talk its way past a guardrail. A call the rules refuse stays refused, whoever asked for it.
- Change anything during the background triage or the postmortem. Both are read-only.
- Promise the cause. The answer is the model’s reading of the evidence it fetched, with every step shown, so you can check it before acting.
- Approve its own access. On a cluster that requires approval to connect, it can request a just-in-time grant; a person approves it.
- Treat what it reads as orders. Logs, tool output and attached files are data, not instructions.
Questions
Before an agent joins the on-call.
Can Runa fix an incident on its own?
Only within its access and your guardrails. Give it a read-only access and it investigates and proposes; give it resource.write and it can restart, scale or re-image what that access names, unless a guardrail stops it.
Does it need playbooks written first?
No. It picks each tool from what the last one returned. If you want a fix written down, it can draft a runbook as a workflow, which stays disabled until a person approves its plan.
Which model does the investigating?
The platform default, or your workspace’s own Anthropic or OpenAI key, or an OpenAI-compatible endpoint. Use is counted in AI credits either way.
Which plan is this?
Incidents, alerts and proposed fixes are part of Team and Enterprise, with 500,000 and 1,000,000 AI credits a month.
Read next
The parts this example uses.
Try it on a test cluster first.
Connect a staging cluster, give Runa a read-only access, break something on purpose, and read what it does.