Runbook-Revenant

Runbook Revenant started as a conversation with a software architect, not as a hackathon idea.

I asked him a simple question: “If you had to point me at a real business gap to build something useful around SRE, what would it be?”

He didn’t talk about “yet another dashboard.” Instead, he pointed out two painful realities:

Incidents already happen in a tool zoo. Teams have Grafana/Datadog/CloudWatch, GitHub, Jira, Slack, runbooks in Notion/Confluence, and postmortems in docs. But when something breaks at 2 a.m., humans still have to stitch all of that together manually in their heads.

Architecture drifts faster than diagrams. We draw clean system diagrams and write careful architecture constraints (“this service only calls that one,” “this path must stay under 200ms”), but once new changes ship, the real traffic patterns and failure modes quietly diverge. The “proposed architecture” and the “actual architecture” stop matching, and nobody notices until something falls over.

Runbook Revenant is my attempt to build directly on those two points.

With Kiro as the code copilot, I designed Runbook Revenant as a multi-tenant incident copilot that:

Pulls in signals from multiple services (alerts, logs, traces),

Groups them not only by trace/correlation IDs, but also by stable business keys and data paths (like orderId, customerId, accountId),

Tracks DataPathFlows over time – which business flows are failing, how often, and in which services,

Surfaces a SLA/SLO watchlist so you can see which services or data paths are about to violate expectations before they actually do.

The “architecture drift” insight shows up very concretely: we keep a clear, spec-driven picture of how incidents should be modeled and how flows should behave, and then we continuously compare that to the real flows and real incidents that Runbook Revenant observes. When they don’t match, it shows up as incidents, watchlist entries, and “haunted” data paths that keep coming back.

So the project isn’t just another incident dashboard. It’s a tool born from a software architect’s warning:

“Your architecture diagram and your production system are never the same thing.”

Runbook Revenant is where I try to close that gap—and make it visible—every time something breaks.