Watch how an investigation actually begins.

An alert fires. Somebody in the channel says "I bet it's the database." Within ninety seconds four people are looking at database metrics, somebody is checking connection pool saturation, and a query is being run against slow logs.

Nobody decided that the database was the cause. One person said it out loud when the team knew the least about what was happening, and that sentence became the plan.

Forty minutes later it turns out to be a deploy that went out at the start of the window.

The bias has a name and a large literature

This is anchoring, and it is followed almost immediately by confirmation bias. Research on premature certainty in incident response describes the mechanism exactly: the first interpretation, formed when the organisation knows the least, becomes the baseline. Every subsequent piece of information gets measured against it. Evidence that agrees is accepted quickly. Evidence that disagrees gets questioned, delayed, or held to a higher standard.

The clinical literature has studied this for decades because the stakes there are higher. Work on diagnostic reasoning describes confirmation bias as hypothesis-driven attention allocation: once a hypothesis is active, it shapes what you go looking for. You order the tests that would confirm it and neglect the ones that would test the alternatives.

Swap clinician for engineer and test for query and you have described every incident bridge I have ever been on.

The uncomfortable finding is that awareness does not fix it. A MITRE study on structured analytic techniques found that a formal method designed to counter this reduced some distortion effects, and had no measurable impact on anchoring at all for experienced analysts. Knowing about the bias is not a defence against it.

Every tool we own makes it worse

Here is the part that I think gets missed, and it is not a people problem.

Observability tooling is built as a search interface. You arrive with a suspicion, you type it in, and the tool returns information about the thing you typed. Grafana shows you the dashboard you opened. A log query returns lines matching the filter you wrote. A trace search returns the service you named.

None of them ever tell you about the five things you did not ask about.

So the tooling is structurally incapable of contradicting you. If the cause was a disk filling on a node nobody mentioned, you will find that out when somebody thinks to look, and not one second earlier. The absence of evidence for the other candidates is never surfaced, because you never generated a query that would have surfaced it.

That is what makes forty-minute detours normal rather than exceptional. The team was not careless. The tools answered every question they were asked, accurately.

Scoring every cause instead of confirming one

This is the design decision in Vörr that I have come to rate most highly, and it took me a while to appreciate why it matters.

When you ask Vörr to work out what caused something, it does not take your hypothesis and go looking for support. It scores every root cause category. Memory. CPU. Disk. Network. Deployment. Dependency. All of them, every time, whether or not anybody suspected them.

What comes back is not a single answer. It is a ranked set with scores attached, including the ones that scored low.

The low scores are the part I did not expect to find useful. A ranked list that says deployment scores high and memory scores near zero has told you two things, and the second one is the expensive one to obtain by hand. Ruling out memory manually means finding the right dashboard, choosing a window, knowing what normal looks like for that service, and satisfying yourself that nothing there is unusual. That is ten minutes and a context switch, per candidate, and it is precisely the work nobody does under pressure. So instead we skip it and stay anchored.

Getting the ruled-out list for free changes the shape of an investigation. You are no longer defending a hypothesis. You are looking at a board.

What it does not do

Worth being straight about the limits, because scoring can look more authoritative than it is.

The scores are only as good as what is connected. A category with no connected source cannot be evaluated, and the honest behaviour is to say so rather than quietly score it zero, which would read as ruled out. Vörr distinguishes between having no source of a given type connected and having a source connected that simply does not cover this particular service. Those are different problems with different fixes, and collapsing them would produce exactly the false confidence the whole approach is meant to remove.

It also does not know your system's history. If this service has failed the same way three times for a reason that never shows up in telemetry, a scoring model will not surface that and a colleague who was there will. Judgement is not being replaced here. What is being replaced is the tedious, skippable work of checking the possibilities you did not think of.

Two habits worth adopting regardless

Say the hypothesis out loud as a hypothesis. There is a real difference between "it's the database" and "my current guess is the database and I am testing it". The second is harder to get anchored to, and it costs nothing.

Then ask what would disprove it before you go looking for what would confirm it. If the answer is that you would expect to see something specific and you have not checked whether it is there, check that first. This is the single most effective thing I have found, and it works because it inverts the search direction that the tooling naturally pushes you towards.

Most incidents are not solved by the first guess. They are solved by the moment somebody abandons it.

Author note

The thing that made this click for me was noticing how rarely anyone in an incident channel says what they have ruled out. We say what we are looking at. We almost never say what we checked and dismissed, which means the same ground gets covered twice and the untouched ground stays untouched.

I do not think that is a discipline failure. It is just that ruling something out is unrewarded work, and under pressure people do the rewarded kind.

Mohan Gopi, Associate DevOps Engineer at Frigga Cloud Labs, where I work on Vörr. Always happy to talk about incident process with people who run it differently. LinkedIn.

Debugging Is Mostly Confirmation Bias With a Terminal