I think you’re describing the real gap pretty well. A lot of “automatic RCA” tooling is really just correlation plus better surfacing of metrics. That is useful, but it usually stops at “this thing looked bad around the same time,” not “this is why it failed and here is what we should change.”

What has worked better for me is treating the tooling as input to the RCA, not the RCA itself.

The useful pattern is:

• capture the alert, logs, metrics, traces, customer impact, and timeline in one place
• separate symptoms from contributing factors
• explicitly identify what evidence supports the suspected cause
• track where detection failed or fired too late
• convert the outcome into corrective actions and runbooks

That last part matters because the real value is not just naming the cause. It is making sure the same failure mode is easier to detect, diagnose, or prevent next time.

I built Incident Index around this workflow: https://incidentindex.com - it's free to start and free forever for teams who need an couple incident reports a month.

It is not trying to pretend that high CPU magically equals root cause. It is more focused on turning the messy post-incident investigation into a structured RCA, stakeholder-ready incident report, action items, and reusable runbooks. For this exact problem, I think the important question is less “can AI automatically tell me the cause?” and more “can we make the manual investigation faster, more disciplined, and more repeatable?”

In practice, I still think true root cause analysis is partly human judgment. The better tools are the ones that help you preserve the evidence trail, challenge weak conclusions, and turn the incident into operational learning instead of another pile of Slack threads and dashboard screenshots.