How I Built an AI Incident Commander That Thinks in Graphs (and Solves 3 AM Outages in 90s)

kalp patel — Sat, 17 Oct 2026 06:13:04 +0000

Built for the **Graph Hacks: Context for AI Agents* Hackathon (WeMakeDevs × FalkorDB) · Track 01 & Track 02*

At 3 AM, three services break at once: checkout-api, cart-service, and orders-service all start timing out. The on-call engineer gets paged. They open five dashboards, grep through logs, and 45 minutes later—after digging through pull requests—they find it: someone reduced a connection pool size in a shared library that everything depends on.

This is the problem SentinelGraph solves. And it solves it in under 90 seconds, using a graph.

Why a Graph Database and Not a Vector Search?

The first instinct when building an AI agent for incident response is to throw logs at a vector database and use semantic search to find "similar past incidents." It feels right. But it misses the most important question an engineer actually asks:

"What do all three broken services have in common?"

This isn't a similarity question. It's a path question. You need to find the shared downstream dependency—the node that lies on the path from every alerting service to something broken. That's a multi-hop graph traversal, not a cosine similarity.

FalkorDB makes this a single Cypher query:


cypher
MATCH (s:Service)-[:DEPENDS_ON*0..5]->(candidate:Service)
WHERE s.name IN $services AND candidate.status IN ['down', 'degraded']
WITH candidate, count(DISTINCT s) AS covering
WHERE covering = size($services)
RETURN candidate.name ORDER BY covering DESC

DEV Community: kalp patel

How I Built an AI Incident Commander That Thinks in Graphs (and Solves 3 AM Outages in 90s)

Why a Graph Database and Not a Vector Search?