I gave this talk at SREday London on September 24, 2026. The deck is embedded above (arrow keys to step through, o for the grid view). What's below is the prose version, so you can read it on its own or follow the slides side by side.

The case study is the Cloudflare outage of 18 November 2025. Everything about it comes from Cloudflare's public postmortem. We did not observe their infrastructure live, and no agent ran during the incident. It is a reconstruction of what a dependency graph would have shown.

Several products, one shared dependency

On 18 November, Workers KV, Access, Turnstile and the Dashboard all failed on the same day, each with a different symptom: elevated errors, authentication failures, failed challenges, login trouble. A large slice of the web behind Cloudflare felt it.

Per the postmortem timeline, customer HTTP errors started at 11:28 and automated detection fired at 11:31. It then took until 13:37 to be confident that a configuration file was the trigger. That is 2h06m from detection to identifying the file.

Detection, investigation and recovery are different parts of the timeline. Monitoring did its job in minutes. The slow part was finding the lead.

Three questions telemetry does not answer

The smaller version of this happens on a shared platform every week. Ten teams ship changes in the last hour, a dependency several hops away fails, and you get paged. Which change?

Three questions decide it:

1. Which dependency path connects to the failing service?

2. What changed on that path during the incident window?

3. Which evidence separates an explanation from a coincidence?

Traces give you runtime relationships and logs give you failure details. Neither carries permissions, generated files or deployment records. A recent change is not automatically the cause, and a downstream service is not automatically affected.

Building the graph from what you already run

The graph is built by reconciling the systems you already have: AWS, Kubernetes, Terraform, GitHub, Jira, Datadog and others. Each one names the same thing differently, so the join is identities, relationships and history in one place.

Then you version it through time. "What changed between 14:23 and 14:47?" becomes a query instead of a guess. A query-time crawl gets you current facts, but it cannot recover history it never collected.

For Cloudflare, the chain runs from a permissions change in one internal database, through a feature file that doubled in size, into the Bot Management engine, and out to every product downstream. That chain was not in the telemetry. It was in the topology.

What an agent does with a graph

An agent walking a graph it did not invent does not have to guess topology from logs. Dependencies on the path give it candidates, not causes, and it still needs evidence to separate the two.

One customer example, unrelated to Cloudflare: MotherDuck's Head of Infra, Hilary Brennan-Marquez, reported that the agent answered in 30 seconds an investigation she estimated at 20 minutes to two hours of manual work. That is one customer's estimate, not a controlled benchmark, and it measures time to an answer, not time to restore. The story is on our testimonials page.

Where the graph stops

Three limits to keep visible in any investigation:

1. Missing relationships. Not in the graph means "we don't know", not "doesn't exist".

2. Stale records. Correct when collected, wrong at incident time. Show freshness and observation time.

3. Dependency is not causality. When several recent changes share a path, logs, artifact inspection and reproduction are what separate them.

The graph organizes evidence. You still validate the explanation and decide the action.

Build or buy

A useful first version is small: one service, its explicit dependencies and its change records help with a recurring investigation. You do not need a complete company model first.

Keeping it correct is the part that never ends. Identities have to be reconciled across sources, APIs change, resources disappear, and historical versions must survive. Someone owns history, coverage and freshness.

I'm on the buy side, but the correctness requirements are the same either way.