An AI SRE watches infrastructure on a schedule, reasons about incidents when something breaks, and turns that reasoning into a fix with a clear path to production. ops0 does this with a 60-second monitoring loop, AI analysis on demand, remediation runbooks and fixes generated as code, and explicit approval gates on deploys, drift remediation, configuration changes, and anything that touches IAM or production state. The 3 AM page becomes a triage already in progress, but humans still decide what changes.
The promise of NoOps was simple: infrastructure so well operated that routine toil disappears. The reality of AI SRE today is more honest: AI absorbs the analysis work, the team keeps the keys.
NoOps the first time around struggled because teams tried to achieve it with the wrong tools. The automation did exactly what it was told, which meant teams had to tell it everything. Every edge case. Every failure mode. Every recovery procedure.
That is not automation. That is scripting.
A useful AI SRE needs systems that understand what they are doing, plus a control model that bounds what they are allowed to do.
What AI SRE Means In Practice
There are two parts: the analysis, and the action.
Analysis is where AI carries the load. The system collects events, pod state, deployment history, drift signals, policy results, and dependency context. When an incident is created or an operator clicks "Analyze," AI reads that context, reasons about likely root cause, and writes a recommendation. Most of the value happens here.
Action is where the team stays in charge. ops0 does not push deploys, modify IAM, scale clusters, or change configuration on its own. Those flows go through dry runs, plan output, policy gates, and explicit approval before a single resource changes.
Always-On Monitoring
The Kubernetes incident monitor in ops0 runs on a configurable interval, default 60 seconds, controlled by incidentMonitoringInterval. Each tick it pulls events, pod status, and workload health from connected clusters, dedupes by incidentKey (namespace, kind, name, reason), and either creates a new incident or updates an existing one with occurrenceCount, firstSeenAt, lastSeenAt, severity, and a JSONB array of raw events.
This is intentionally not a real-time event stream. A scheduled loop is more stable, deduplicates better, and gives AI analysis a coherent window of context to reason about rather than firing on every transient event.
Around that loop, ops0 ingests deployment history, IaC drift findings, policy check results, container vulnerability scanning data, Kubernetes policy check decisions, and per-namespace Kubernetes cost allocation when those integrations are enabled. That is the situational awareness layer the AI reasons against.
What AI Does With That Data
AI analysis is a triage assist, not a fix executor. When an incident is created or a user clicks Analyze, ops0 sends the structured incident plus its raw events to the AI backend. The result populates aiAnalysis (a human-readable summary) and aiRecommendations (suggested next steps). aiAnalyzedAt records when the analysis was last refreshed.
The output is not a button that runs against production. It is a triage view: likely cause, recently changed resources to inspect, suggested commands or manifest changes, and a short list of next actions. The team decides what to apply.
That separation is what keeps AI useful in production without giving it write access to a live cluster.
How Remediation Works
ops0 does remediate. It never does it silently. Every fix takes one of four governed paths:
Fixes as code. Infrastructure, drift, and access findings become generated Terraform or OpenTofu changes. A least-privilege finding, for example, produces tightened IAM policy as HCL in a Terraform project. The fix runs through plan, policy checks, cost, and approval like any other change.
Runbooks. IaC and Kubernetes incidents carry AI analysis, recommendations, and a remediation runbook, so the on-call engineer starts from a plan instead of a blank page.
Operator actions. For Kubernetes, an authorized operator can apply a reviewed YAML change or take a supported live action from the incident context, and the resource changelog records it.
Workflows. When a runbook proves itself, the team can turn it into a workflow that combines deployment, script, Kubernetes, and approval steps, triggered manually, on a schedule, or by webhook. The automation is the team's own, with approval steps where they choose.
What Always Requires Approval
The approval gates are the spine of the control model. They live in dedicated tables and execution paths, not in soft policy.
IaC deployments follow plan, dry-run, approval, then apply. The dry run executes with check and diff flags so no resource changes. The execution loop yields awaitingApproval until a human signs off, then runs the apply.
Configurations have an approvalStatus field. Deployments block until the status reaches approved.
Workflow steps that touch sensitive paths use workflowApprovalRequests with expiry and required admin sign-off before the step proceeds.
IaC policy violations from IaC security scanning and custom policy rules block deployment at warning severity or higher. The block is a wall, not a warning.
Drift remediation is detected automatically and analyzed by AI, but the actual reconciliation runs through the same approval-gated deploy path. The system never reconciles drift on its own.
A Real Triage Path
A useful triage with this model looks like this.
3 AM. The monitor loop fires. A CrashLoopBackOff incident is created in the payments namespace with severity P1, occurrenceCount climbing, lastSeenAt two minutes ago.
The incident detail view groups the related raw events, the recent deployment that changed the image tag, a critical finding from container vulnerability scanning on the new image, and the AI analysis: likely cause is the image rollout, recommended next step is a rollback PR.
The on-call engineer wakes up to a Slack message and a populated incident view: AI analysis, the recent deploy, the vulnerable image, the rollback PR ready to merge. They merge the PR, the rollback runs through the normal approval-gated deploy path, drift detection confirms the rollback, and the incident is resolved with a status_change note that links back to the rollback.
The team did not get a vague page at 3 AM. They got a triage already in progress with the next action obvious.
What Humans Still Do
AI SRE does not mean no people. It means less work spent assembling context and more work spent on the decisions that matter.
Set policy. Define the policies, approval requirements, alert rules, and escalation paths the system works within.
Approve writes. Sign off on deploys, drift reconciliation, configuration changes, and any change that touches IAM, secrets, or production data.
Handle the novel. AI is good at incidents that match known patterns. New failure modes still need human judgment, and the system is built to surface them rather than guess.
Make strategic calls. Cloud migrations, architecture changes, scaling strategy, regional failover, vendor selection. These are not operational decisions.
Review and improve. Look at how incidents were analyzed and resolved, then tune alert rules, runbooks, and policies based on what happened.
ops0's Approach
ops0 was built around always-on AI analysis with human-approved action.
The monitoring is continuous and lightweight, designed to feed observability platforms without the overhead of heavier agents. Deployments, configuration changes, resource utilization, drift, dependency health, Kubernetes events, and policy results all enter one structured incident model.
AI reads context with the right awareness. It knows that latency at 3 AM is unusual, that a deployment went out, what the service dependencies are, and which resources are unmanaged by IaC.
Remediation is real, and it is governed. AI explains what happened and drafts the fix or runbook. Infrastructure fixes run through code, policy checks, and approval, and anything automated is a workflow the team wrote and chose to run.
This is what an AI SRE looks like. Not no people, less toil. Not no control, sharper control. Not no observability, observability that reasons.
What is an AI SRE?
An AI SRE continuously watches infrastructure, reasons about incidents using AI analysis, and drafts fixes. In ops0, those fixes reach infrastructure through reviewed code, approval gates, or workflows the team defines.
Does ops0 take action on infrastructure on its own?
Not silently. ops0 has a remediation path, and it is governed: AI analysis explains the likely cause and drafts a fix or runbook, infrastructure fixes are generated as code and go through plan, policy checks, and approval, and any automation runs as a workflow your team defined, with approval steps where you choose.
How are Kubernetes incidents detected?
A monitor loop runs on a configurable interval, default 60 seconds. It pulls events, pod status, and workload health, dedupes by namespace, kind, name, and reason, and creates or updates an incident with severity, occurrence count, and a raw event window.
What does AI analysis do?
AI analysis populates aiAnalysis and aiRecommendations on each incident with a likely cause, recently changed resources to inspect, and suggested next steps. It is a triage assist, not a fix executor.
What infrastructure signals does ops0 reason against?
Deployments, configuration changes, drift findings, Kubernetes events, container vulnerability scanning and Kubernetes policy check results, per-namespace Kubernetes cost data, and dependency context from Resource Graph.
