Used Graphify to turn incidents into a queryable knowledge graph

Built on graphify, a tool inspired by Andrej Karpathy's LLM Wiki idea — instead of rediscovering knowledge from scratch on every query, have an LLM build a persistent, structured knowledge graph that grows richer over time. Graphify takes any folder of files and turns it into a queryable graph with communities, connections, and confidence scores. This fork points it at the Rootly API.

Connect the Rootly API, collect incidents, alerts, teams, and the service catalog for a selected time window, export them into a local corpus, and turn that corpus into a queryable knowledge graph. Use graphify rootly for collection and /graphify in Claude Code or Codex when you want deeper semantic analysis on top.

Fresh install (Graphify + Rootly importer):

pip install "graphifyy[rootly]"
graphify install # Claude Code
graphify install --platform codex # Codex

Add Rootly importer to an existing Graphify setup:

pip install "graphifyy[rootly]" --upgrade

Create a .env file in your project root:

ROOTLY_API_KEY=rootly_...

Fetches incidents, triggered alerts, and teams. Builds the initial graph with severity colors, alert filters, and team/service layers.

graphify rootly

Non-interactive:

graphify rootly --api-key-env ROOTLY_API_KEY --days 30 --mode standard

Outputs written to graphify-rootly-data/graphify-out/:

• graph.html — open in browser to explore the graph
• GRAPH_REPORT.md — god nodes, communities, suggested questions
• graph.json — raw graph for querying

Runs parallel subagents over the incident corpus to infer cross-incident themes, recurring patterns, and root cause relationships.

Claude Code — type in the chat:

/graphify graphify-rootly-data --mode deep

Codex — type in the chat:

run graphify on graphify-rootly-data --mode deep

| Pattern | What it shows | Why a graph helps | |---|---|---| | Service incident heatmap | Which services are on fire and how badly. Node size = incident count, color = worst severity. | Clusters services that tend to fail together, revealing hidden infrastructure dependencies. | | Team on-call & escalation map | Who covers what across all schedules and escalation policies in one view. | Spots single points of failure — the person on 4 schedules across 3 teams — and coverage gaps. | | Alert-to-incident funnel | Which alert sources produce real incidents vs. pure noise. | An alert source with 200 alerts and 0 incidents is immediately visible by node size. | | Incident → action item follow-through | Are we actually fixing what breaks? Solid edges = completed, dashed = open. | Clusters of open action items around a team or service expose systematic follow-through problems. | | Cross-service failure correlation | Which services fail together within the same time window. | Community detection finds shared-fate groups that likely depend on the same underlying infrastructure. |

Clustering is graph-topology-based — no embeddings. Leiden finds communities by edge density. Semantic similarity edges influence community detection directly. No separate embedding step or vector database required.

Every relationship is tagged EXTRACTED (found directly in source), INFERRED (reasonable inference, with a confidence score), or AMBIGUOUS (flagged for review).

God nodes — highest-degree incidents or services (what everything connects through)

Confidence scores — every INFERRED edge has a confidence_score (0.0–1.0). EXTRACTED edges are always 1.0.

Token efficiency — the first run extracts and builds the graph (costs tokens). Every subsequent query reads the compact graph instead of raw markdown — that's where the savings compound.