An alert fires. Checkout latency, p95, over threshold.

What you have been handed is a pod name and a number. What you need is a function in a file in a repository, changed by a commit, shipped by a deployment, roughly forty minutes ago.

Between those two things sits a chain of relationships that nobody wrote down:

alert
→ affects service
→ implemented by API
→ handled by function
→ changed in commit
→ included in deployment
→ queries table
→ table shows latency increase

Seven hops. Every one of them is a join between two systems that do not share an identifier, and we perform that join manually, at speed, under pressure, at three in the morning.

That is what production debugging actually is. Not log search. Graph traversal, done by hand, with a human as the index.

Where each hop breaks

Worth walking it properly, because the failures are specific rather than general.

Alert to service. The alert names a pod. The pod name contains a deployment name, which contains something resembling a service name, which may or may not match what your repository is called. This is string manipulation on a convention nobody documented.

Service to code. Which repository is this? On a good day it is obvious. On a normal day the service was renamed, split, or absorbed, and the repository name is a fossil of an earlier decision.

Code to change. What actually shipped? Your CI system knows it deployed an artifact. Whether that artifact carries the commit it was built from is a decision somebody made once, and if they did not, you are matching timestamps between a pipeline log and a git history.

Change to behaviour. The commit touched four files. Does any of that reach the slow path? Answering that means reading the diff and knowing what calls what, which is another traversal inside the code itself.

Behaviour to data. The changed function queries something. Which table, and is that table currently unhappy? This hop is where most people give up and go back to staring at dashboards.

Nothing in that list is intellectually hard. All of it is slow, and it is slow in the exact conditions where slow is expensive.

The odds are not in your favour

It is worth being blunt about how often the answer is a deployment.

DORA's 2025 data has only 16.7% of respondents reporting a change failure rate of 4% or lower, with lower-performing teams sitting somewhere between 46% and 60%. Nearly half of deployments causing something.

And the input volume has changed. DX's 2026 analysis reports 91% developer adoption of AI and over 20% of merged code now AI-authored, noting that velocity has risen faster than quality. Their conclusion is worth repeating: if the underlying process is broken, AI helps you ship the mistakes faster.

So more change, arriving quicker, with roughly the same failure rate. Which means "what changed" is not one hypothesis among many. It is usually the answer, and the traversal to confirm it is the expensive part.

Walking it

Here is the same alert, traversed rather than searched.

Checkout latency is up. First question is whether this is the service or something underneath it, because those lead to completely different afternoons. Checkout depends on a payments service and a database, and Vorr AI already holds those relationships, so that is one question rather than three consoles. Both look healthy. The problem is local.

Next question is what changed. Not what deployed to checkout specifically, but what changed anywhere in the last hour, because the thing that broke checkout might have shipped to something checkout calls. That question is only askable because Vorr AI pulls deploy events from every connected CI system onto one timeline. A deployment landed forty minutes before the latency moved, which is suggestive rather than conclusive and needs testing rather than believing.

The commit touched four files. Three are irrelevant on inspection. The fourth changes a function, and the useful question is not what that function does now but whether anything on the checkout path reaches it. Vorr AI traces callers across every connected repository rather than the one I happen to have open, which matters here because the function lives in a shared library and the caller does not.

It does reach it. That function queries a table, and the table's latency moved at the same time as the deployment. Code and telemetry are answers from the same graph, so putting those two facts next to each other does not involve translating a service name into a repository name into a metric label.

At that point I have a chain rather than a hypothesis, and every link carries its source: a repository, a file, a line, a commit, a deploy event, a metric. That evidence trail is the part I would not give up. During an incident there is a large difference between telling three colleagues what I think happened and showing them the line.

The reasoning is still mine throughout. What Vorr AI removes is the twenty minutes of assembly between each thought.

Access is not the same as understanding

There is a version of this that looks solved and is not, and it is worth separating.

You can give an AI assistant access to your cloud, your repositories and your cluster. Plenty of teams have. What that produces is a system that can query each of those things individually, which is genuinely useful and is not the same as knowing that this pod runs this service which is built from this repository.

Access gives you the ability to fetch. Context gives you the ability to traverse. Given the alert above, an assistant with access can tell you a great deal about the pod, and cannot get you to the commit, because the edge between those two facts does not exist in any of the systems it can reach. It exists in the relationships between them, and somebody has to build that.

This is the distinction I would hold on to when evaluating anything in this space, including ours. Ask what a tool knows about the relationships between your systems, not what it can query inside them. The first is context. The second is a connector, and you probably already have several.

What I would check on your own setup

Time the traversal, not the incident. How long from alert to naming the commit? That number is almost never measured and it is usually most of your MTTR.

Check whether your deploy artifacts carry their commit. If they do not, every incident includes a timestamp-matching exercise, and that is a one-time fix in your pipeline.

Count the identifier translations in your chain. Pod to service to repository to pipeline. Every mismatch is a manual step and a chance to be confidently wrong.

Then ask who can do the whole traversal. If it is two people, your recovery time is a property of their availability rather than of your systems.

The alert will always know the pod. Something has to know the rest, and right now, for most teams, that something is a person.

Author note

What changed my thinking here was noticing that I could not name a single incident where the hard part was reasoning.

The hard part was always assembly. Getting the pieces into one place in the right order, at which point the answer was usually obvious to everyone at once.

That is a fairly encouraging thing to conclude, because assembly is a solvable problem and insight is not.

Mohan Gopi, Associate DevOps Engineer at Frigga Cloud, working across AWS, GCP and Azure. I work on Vorr AI, which connects code, cloud, deployments and monitoring so an engineering question can be answered from the state of the system rather than from a guess. LinkedIn.

The Alert Knows the Pod. The Pod Doesn't Know the Commit.