🔁 Finding Similar Past Incidents With AI: Stop Rediscovering the Fix

There’s a special kind of frustration that hits about forty minutes into an incident, when you finally figure out the cause and realize: we’ve seen this before. Maybe not you, maybe a teammate, maybe last quarter, maybe under a slightly different symptom — but somewhere in your pile of past postmortems is a document that would have saved you those forty minutes. The knowledge existed. It just wasn’t findable when you needed it.

This is one of the clearest, lowest-risk wins for AI in incident response: not deciding anything, not touching production, just helping you find the past incident that rhymes with the one you’re living through right now.

Why your incident history is a graveyard, not a library

Most teams write postmortems and then never read them again. They live in a wiki folder, a Google Drive, or a ticketing system, organized by date, titled inconsistently, and searchable only by exact keyword. So when checkout starts timing out, a keyword search for “timeout” returns 200 documents and you give up.

The problem isn’t that the knowledge is missing. It’s that retrieval is broken. Symptoms vary (“checkout slow” vs. “payment latency” vs. “P99 spike on orders”) even when the underlying cause — say, a connection pool exhausting under load — is identical. Keyword search can’t bridge that gap. Semantic similarity can, and that’s what AI brings.

The pattern: describe the symptom, get back the matches

The workflow I like is simple. When an incident kicks off, I describe what I’m seeing in plain language — “checkout requests timing out, started around 2am, error rate climbing, no recent deploy I can see” — and ask the model to find past incidents that match the shape of the problem, not just the words.

For this to work, the model needs access to your incident corpus. Two practical ways:

1. Paste-in for small corpora. If you have a few dozen postmortems, paste the relevant batch and ask: “Which of these past incidents most resembles the following active symptom? Rank the top three and explain why for each.”
2. Retrieval over a larger corpus. For hundreds of incidents, you index them and let the assistant retrieve the semantically nearest ones. The mechanics differ by setup, but the goal is the same: surface the three or four most-similar prior incidents and their resolutions.

Pro Tip: Have the model explain why each past incident matches, not just that it matches. “This one matches because both involve connection-pool exhaustion triggered by a traffic spike” is useful. A bare ranked list invites you to trust a match that’s actually superficial — same words, different cause.

Treat the match as a lead, never a diagnosis

Here’s where discipline matters. A similar past incident is a hypothesis generator, not an answer. The model finding that last March’s outage looks like tonight’s does not mean tonight’s cause is the same. It means: “go check whether the thing that broke last March is broken again.” That’s a lead worth following, and it can collapse your triage time dramatically — but you still confirm it against live signals.

I’ve watched this go wrong: someone finds a similar-looking past incident, assumes the same root cause, applies last time’s fix, and makes things worse because this time it really was something else. The AI didn’t fail — the human stopped thinking. The match accelerates investigation; it doesn’t replace it. AI for synthesis and retrieval; humans for the diagnosis and the fix.

The flywheel: better postmortems make better matches

The quality of your matches is downstream of the quality of your postmortems. If your past incidents are vague (“stuff was slow, we restarted it, it got better”), no amount of AI will make them retrievable in a useful way. If they capture the actual symptom and the actual mechanism and the fix, then future-you gets a real library.

This is a quiet argument for writing good postmortems even when you’re exhausted: you’re not writing for the regulator, you’re writing for the engineer at 3am next year who has this exact problem. A well-structured corpus is what makes retrieval pay off, and the incident-response category has detailed guidance on writing postmortems that future-you can actually use.

Wiring it into the response flow

The cleanest integration is to make “search prior incidents” a standard early step in your runbook, right after triage. The free AI Incident Response Assistant can take your symptom description and help structure the search, and keeping a consistent “find similar incidents” prompt in your prompt workspace means everyone on call runs the same play instead of relying on whoever happens to remember last quarter.

For the model itself, anything strong at semantic understanding works — Claude and ChatGPT both do this well. If you’re privacy-constrained and want something you can run locally over sensitive postmortems, a model like Gemma is worth evaluating.

The honest framing

I want to be precise about the value here, because it’s easy to oversell. AI doesn’t know your systems. It can’t tell you what’s broken tonight. What it can do is make your own institutional memory retrievable at the exact moment you need it — turning a graveyard of postmortems into a searchable library. The fix is still yours to find and yours to apply. But starting from “we’ve seen something like this, here’s where” beats starting from a blank dashboard at 3am every single time.

For reusable framings and search prompts, browse the prompt library.