When production goes down, the first ten minutes are not about fixing. They are about asking questions. What else will break? Who knows this system? Has this happened before?
The answers exist, but they are scattered across a service map, a team chart and old postmortems. Someone has to stitch them together by hand, under pressure. That is the problem I wanted to solve for Graph Hacks by WeMakeDevs and FalkorDB.
What I built
Incident Brain is an agent that keeps its context in a FalkorDB graph. You type something like "payments-api is returning 500 errors", and it answers with:
- Blast radius: every downstream service affected, by hop distance
- Who to ask: people ranked by ownership and hands-on experience
- Similar past incidents: root cause, fix and who fixed it
- Proof: the exact nodes, edges and Cypher behind each claim, highlighted in a live graph
Then you can log the incident. It is written back to the graph, so the next similar outage finds it.
Why a graph?
These questions are all about connections. "What breaks if this service fails?" is a multi-hop problem. In SQL it means recursive joins. In FalkorDB it is one readable query:
MATCH (f:Service {name: $name})<-[:DEPENDS_ON*1..4]-(s:Service)
RETURN DISTINCT s.name
That single query became one tool the agent can call. The agent never guesses. Every fact in its answer comes from a tool that ran a Cypher query and returned real nodes and edges.
How FalkorDB is used
- Multi-hop traversal for the blast radius
- shortestPath to explain why one service impacts another
- Graph algorithms (PageRank) to rank affected services by importance
- Persistent memory: each logged incident becomes a node with AFFECTED, FIXED_BY and SIMILAR_TO edges, so memory survives restarts
- Multi-graph support: a shared company graph plus a separate memory graph per team
If you remove FalkorDB, the product stops working. The graph is not decoration, it is the brain.
The stack
Python, FastAPI, the official FalkorDB Python client, LLM tool calling, a force-directed graph view in the browser, and Docker. The whole thing starts with one command: docker compose up.
A challenge I hit
[Replace this with your real challenge. Example: "My first version let the model answer from its own knowledge, and it invented a service that did not exist. I fixed it by forcing every answer to come from tool results and returning node IDs as sources." Use whatever really happened.]
What I learned
[Write 2 or 3 honest lines from your experience. Example: "Designing the graph schema first made everything else easier. Once relationships were clear, the tools were small and simple."]
Try it
- Live demo: [https://incident-brain-ashen.vercel.app/ ]
- GitHub: [https://github.com/vidishagupta/incident-brain ]
- Demo video: [https://youtu.be/tgIFDHjhuek?si=hZQJeaH4cgNR8uqV ]
Built for #GraphHacks with FalkorDB and WeMakeDevs. If you build agents, try giving them a graph. The difference between guessing and following relationships is big.
Top comments (1)
Amazing 🤩