The pitch for "AI in operations" is often oversold: an assistant that finds the root cause and fixes it for you. That's not what's reliable today, and treating it as such is how teams end up with an AI-shaped false sense of safety. What is reliable — and genuinely useful at 3am — is narrower and more mechanical than that pitch suggests.
What it's good at: assembling the timeline fast
An incident investigation starts the same way almost every time: gather what changed, when, and what the telemetry looked like before and after. That step is pure retrieval and correlation across deployments, config changes, alerts, logs and traces — exactly the kind of structured-but-tedious task a model can compress from fifteen minutes of dashboard-hopping into a single, reviewable summary.
Feed it the right inputs — recent deploys, alert history, relevant log windows, the on-call runbook for the affected service — and it can produce a first-draft timeline on arrival: what changed in the last N hours, which of those changes overlaps with the alert firing, and which logs correlate. A human still reads that timeline before acting on it, but reading a draft is faster than building one from scratch.
What it's good at: log and event triage
Kubernetes events and application logs during an incident are noisy by nature — most of it is irrelevant. Pattern-matching across thousands of log lines to surface the handful that actually correlate with the failure mode is a task models handle well, provided they're grounded in the actual log data rather than asked to guess from a description. The output is a shortlist for a human to verify, not a verdict.
What it's not good at: deciding what's safe to do
Rolling back a deployment, scaling a node pool, restarting a stateful service — these are actions with blast radius, and the judgment call about whether an action is safe given the current state of the system belongs to the engineer who owns that judgment, not to a model inferring from a summary. The useful pattern here is suggestion plus explicit human approval, not autonomous remediation, for anything that isn't already a pre-approved, narrowly-scoped runbook step.
What it's good at, after the fact: postmortem drafting
Once an incident is resolved, turning the raw timeline, Slack thread and graphs into a readable postmortem is exactly the kind of synthesis work models are well suited for — a first draft that a human edits for accuracy and tone, rather than a blank page nobody gets around to filling in. Postmortems that don't get written are postmortems that don't prevent the next incident; lowering the friction to produce a first draft measurably increases how many actually get written.
The pattern that works
The operations platforms we build treat AI as an accelerant on investigation and documentation — timeline assembly, change correlation, log triage, draft postmortems — with every suggested action routed through the engineer who's actually on call. That keeps the speed gains where they're real, and keeps control where it needs to stay.