{"id":4934,"date":"2026-08-26T09:11:45","date_gmt":"2026-08-26T09:11:45","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/26\/automated-diagnosis-isnt-automated-understanding-what-postmortems-teach-us-about-building-trustworthy-incident-ai\/"},"modified":"2026-08-26T09:11:45","modified_gmt":"2026-08-26T09:11:45","slug":"automated-diagnosis-isnt-automated-understanding-what-postmortems-teach-us-about-building-trustworthy-incident-ai","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/26\/automated-diagnosis-isnt-automated-understanding-what-postmortems-teach-us-about-building-trustworthy-incident-ai\/","title":{"rendered":"Automated Diagnosis Isn\u2019t Automated Understanding: What Postmortems Teach Us About Building Trustworthy Incident AI"},"content":{"rendered":"
\"\"<\/div>\n

\"\"<\/p>\n

Anyone who\u2019s ever been on an on-call rotation knows the feeling. A dashboard lights up green to red across a dozen services, an incident channel starts filling with theories and somewhere in that noise is one root cause hiding behind six symptoms that all look equally suspicious. Fixing the problem is rarely the hard part. Figuring out what the problem actually is- that\u2019s where the time is spent.<\/p>\n

So, when yet another vendor pitch promises that AI has solved this (point a model at your telemetry and it tells you what broke), part of me wants to believe it. Honestly, some of that promise is real. However, the more time you spend around incident response, the easier it gets to spot claims that skip past the hardest part of the job. Finding symptoms is easy; understanding causes is not. This is just my opinion on where that gap actually sits, and what it would really take to close it.<\/p>\n

The Gap Between Correlation and Diagnosis<\/h3>\n

Look closely at what most \u2018AI-driven root cause analysis\u2019 tools actually do, and a pattern starts to show up. They\u2019re very good at telling you that 47 alerts are all part of the same problem. They\u2019re much less reliable at telling you what that problem actually is. Alert correlation, topology mapping, and noise reduction are genuinely useful capabilities that meaningfully reduce the time an engineer spends on triaging. However, grouping related symptoms isn\u2019t the same thing as identifying a cause.<\/p>\n

That distinction isn\u2019t just semantics. It\u2019s the difference between an engineer opening an incident channel to \u201chere are the 12 things that fired around the same time\u201d versus \u201chere\u2019s why they fired, in that order, and here\u2019s what to fix.\u201d The first still needs a human to do the actual diagnostic reasoning. The second means the system has built something closer to a real causal model, an understanding of how a change three services upstream produced a symptom two hops downstream, three minutes later.<\/p>\n

Most tools on the market today are much closer to the first category than they\u2019d like you to believe.<\/p>\n

Sketching What Real Diagnosis Looks Like<\/h3>\n

If correlation is \u201cthese things happened together,\u201d diagnosis is \u201cthis happened because of that.\u201d Getting from one to the other isn\u2019t just a matter of bolting on more dashboards. It\u2019s a genuinely different process, and I think it\u2019s worth actually sketching out instead of leaving it vague.<\/p>\n

At a high level, a system capable of real causal diagnosis needs to move through like this:<\/p>\n

\"\"<\/p>\n

The step that quietly gets skipped is testing causal direction. Does perturbing the upstream service actually explain the downstream symptom, or are the two just moving together? Most tools stop at correlation dressed up as causation, because that step is genuinely hard to build. Matching against incident history is where organizational discipline comes into play, since that knowledge base doesn\u2019t build itself. The confidence check at the end, the part where the system is willing to say, \u201cI\u2019m not sure, escalate this,\u201d is the one I\u2019d trust least to actually exist in most tools being sold today. Uncertainty doesn\u2019t make for a great product demo.<\/p>\n

Where This Gets Harder: Non-Deterministic Systems<\/h3>\n

All of this is already hard for traditional infrastructure, where failure modes are at least somewhat bounded and repeatable. It gets a lot harder once AI and LLM-based components are part of the system you\u2019re trying to diagnose.<\/p>\n

The traditional signals SRE teams have leaned on for a decade (latency, traffic, errors, saturation), all assume a system that behaves the same way twice given the same inputs. A RAG pipeline or an agentic workflow doesn\u2019t offer that guarantee. The same request can fail differently on different days for reasons that have nothing to do with infrastructure health: A shift in retrieved context, a subtle change in model behavior and a guardrail stepping in somewhere unexpected. A diagnostic system trained to reason about deterministic failure patterns will confidently give you the wrong answer here, and it\u2019ll say it with the same tone of authority it uses when it\u2019s right.<\/p>\n

That\u2019s the part that worries me most, honestly, more as a leader than as an engineer. An automated system that\u2019s occasionally, confidently wrong isn\u2019t neutral. It actively erodes an on-call engineer\u2019s willingness to trust it, often for good, after just one bad call. Trust, once a team loses it in a tool, is brutally hard to earn back. It\u2019s not uncommon to see decent tooling get quietly abandoned after exactly this kind of incident, and it rarely comes back into rotation once that happens.<\/p>\n

The Human-in-the-Loop Argument, Restated<\/h3>\n

None of this is an argument against automating incident diagnosis. The toil is real, the pages at inconvenient hours are real and the case for AI assistance in incident response is a strong one. It\u2019s an argument for being precise about what\u2019s actually being automated, and for treating the postmortem, not the dashboard, as the real training ground for these systems.<\/p>\n

A good postmortem is a structured record of a causal chain that a human worked out under pressure. That\u2019s exactly the kind of data the \u2018match incident history\u2019 step in the flow above needs to work well. This is where leadership matters just as much as architecture. A team that treats postmortems like a checkbox exercise, written thin and fast just to close out a ticket, is quietly starving its own diagnostic tooling of the one input that would actually make it smarter. A team that puts real-time into writing specific, causally clear postmortems, even when it\u2019s tempting to just write \u201cflaky network\u201d and move on, is building the training data for tomorrow\u2019s automation. Whether or not anyone thinks of it that way in the moment.<\/p>\n

This is one of the more underrated jobs of an engineering leader right now. It\u2019s not about picking the right AI vendor; it\u2019s about making sure a team\u2019s own incident discipline is good enough to be worth automating in the first place.<\/p>\n

A Practical Checklist<\/h3>\n

Before adopting or building automated incident diagnosis, a few questions are worth asking honestly:<\/p>\n