Traversal

AI Incident Response, Condensed

• Traversal is an AI site reliability engineering platform that investigates production incidents and identifies their root cause automatically, rather than only alerting that something is wrong.
• The Production World Model is the foundation — a dependency graph the vendor states spans over 1.7 million nodes across 30+ resource types, so the system knows how your infrastructure actually connects.
• A Causal Search Engine traverses that graph, tracing an incident across services, dependencies and recent changes to isolate the cause and a remediation path.
• Named customers include DigitalOcean, Cloudways and American Express, with DigitalOcean cited as cutting mean time to resolution 38% and finding causes in under a minute rather than an hour.
• It is New York based, contact-sales, and enterprise-shaped — there is no self-serve entry point.

Architecture, Results And Company

Alerting Was Solved. Diagnosis Was Not.

Observability has been a well-served category for fifteen years, and it solved a specific problem completely: knowing that something is wrong.

Metrics, logs, traces, dashboards, alerting — a modern production estate emits enormous quantities of signal, and detecting anomalies in it is genuinely mature technology.

What none of that answers is the question an on-call engineer actually has at 3am. Not is something broken — the pager already said so — but which of the forty things that changed in the last six hours caused this.

In a distributed system that question is genuinely hard, and it gets harder as architecture gets more granular. A checkout failure might originate in a payment service, or in a database connection pool, or in a config change to a service two hops away that nobody associates with checkout, or in a dependency's dependency degrading in one region.

The human process is manual graph traversal: an engineer holds a mental model of the system, forms a hypothesis, checks a dashboard, revises, repeats. The quality of that mental model is why one engineer resolves in ten minutes what another takes three hours to find.

Catching the defect before release is a different discipline entirely, and where testing platforms like Functionize sit. Building that model explicitly, as a graph the machine can walk, is the entire idea here — and it is the right idea, because the bottleneck was always diagnosis rather than detection.

The pager tells you something is broken. It has never told you which of the forty things that changed today broke it, and that gap is where the whole night goes.

Why The Dependency Graph Is The Hard Part

The Production World Model is the substantial engineering claim here, and it is worth understanding why it is difficult rather than accepting the number.

1.7 million nodes across 30+ resource types describes a large estate — services, containers, databases, queues, load balancers, config objects, cloud resources. Building that map is not the difficult part. Keeping it accurate is.

Production changes constantly. Deployments, autoscaling, configuration updates, infrastructure drift. A dependency graph built on Monday describes a system that no longer exists by Thursday, and a stale graph produces confidently wrong causal conclusions — which is considerably worse than no conclusion during an incident.

This is the specific thing to interrogate in an evaluation. How is the graph maintained, how quickly does it reflect a deployment, and what happens when it encounters something it has not mapped?

The related question is coverage of the parts nobody instruments. Most estates have a legacy component, a third-party dependency, or a service someone built in 2019 that emits almost nothing. Causal reasoning stops at the boundary of what the graph knows, and those unmapped corners are disproportionately where incidents originate.

Pull request review assistance from GitHub Copilot works from the code alone. The Code Resilience feature — bringing production context into pull request analysis — is the interesting inversion of this. Using the same graph to warn that a change touches something fragile is arguably more valuable than diagnosing the outage it would have caused.

Reading The MTTR And Accuracy Figures

The published results are more specific than most vendors offer, which is to their credit, and they still need reading carefully.

The strongest thing about them is that several are attributed to named companies. DigitalOcean at 38% MTTR reduction and Cloudways at 70% are attached to real organisations rather than being anonymous composites, and that is a meaningfully higher standard of evidence than the category norm.

Two things still need holding in mind. MTTR is an average dominated by outliers. A large reduction can come from fixing a handful of long incidents rather than from improving typical ones — which is genuinely valuable and is a different claim from everything getting faster.

RCA accuracy of 80–82% means one investigation in five is wrong. That is a strong number for automated causal reasoning and it is also the number that determines how you use the tool. An engineer who trusts it completely will, one time in five, spend the incident pursuing the wrong system while the real problem continues.

The correct posture follows directly: treat the output as an extremely well-informed first hypothesis with its evidence attached, not as an answer. The evidence-backed framing the vendor uses is the right one, because a conclusion you can check is far more useful than a conclusion you must trust.

The 6,000 engineering hours saved annually at a Fortune 50 firm is the figure that best captures the actual value — the cost of incidents is overwhelmingly people's time.

1. Replay incidents you have already resolved and compare the tool's conclusion with your own post-mortems.
2. Include the incidents that took longest — those are where MTTR reduction actually comes from.
3. Deliberately test a component that is poorly instrumented, to find where the graph's knowledge stops.
4. Check how quickly the dependency graph reflects a deployment you make during the trial.
5. Run it in advisory mode alongside on-call before letting any self-healing action execute.

Self-Healing Deserves Its Own Governance

Converting a diagnosis into an automated remediation is where this stops being an analysis tool and starts being something that changes production by itself.

The appeal is obvious. If the system knows the cause and the fix is a known action — restart a service, roll back a deployment, scale a pool — executing it immediately resolves incidents faster than any human can.

The risk follows directly from the accuracy figure. Automated remediation acting on a wrong diagnosis does not merely fail to fix the incident; it takes an unnecessary action during an outage, which can compound the problem or introduce a second one.

So the governance questions are the ones to settle before deployment rather than after. Which actions can run unattended and which require approval. What the blast radius of each automated action is. How you stop it mid-execution. Whether every action is logged in a form an auditor or a post-mortem can reconstruct.

Traversal Workers — agents that act proactively and unprompted — raise this further, and the sensible adoption path is the conservative one: advisory first, then automation on a small set of low-risk, well-understood actions, then expansion only where the record justifies it.

Incident coordination platforms such as incident.io approach the same problem from the process end. For regulated environments there is an additional dimension. Automated changes to production systems frequently sit inside change management controls, and an agent acting unprompted needs to be reconciled with those processes rather than routed around them.

• Define which remediations may run unattended and which need approval
• Establish the blast radius of every automated action before enabling it
• Confirm there is a reliable way to halt an action mid-execution
• Ensure every automated change is logged for post-mortem and audit
• Reconcile unprompted agent actions with your change management controls

On-Call Vocabulary Used Here

Five terms from incident response that this listing assumes.

SRE

Site reliability engineering — the discipline of running production systems reliably, blending software engineering with operations.

MTTR

Mean time to resolution. An average, and therefore heavily influenced by a small number of very long incidents.

Root cause analysis

Determining what actually caused an incident, as distinct from what first alerted. The expensive part of on-call.

Alert fatigue

The state where so many alerts fire that engineers stop reacting to them, which is how genuine incidents get missed.

Blast radius

How much of a system an action or failure can affect. The key question before allowing anything to remediate automatically.