SRE Runbook AI

The problem

When an alert fires at 2am, the first 10-15 minutes go to the same repetitive work every time: reading the alert, guessing likely causes, remembering which runbook applies, deciding severity, and drafting a status update, all before you've touched the actual fix. That triage tax gets paid by every on-call engineer, on every incident, regardless of how experienced they are. Teams write runbooks to solve this, but runbooks go stale, live in five different wikis, and don't adapt to the specific alert in front of you.

Who feels it

On-call engineers at any team running production services with paging (Datadog, PagerDuty, CloudWatch). Teams without a dedicated incident commander feel it hardest, since there's no one to do the triage thinking for you.

What I built

A tool that takes a raw alert (the actual payload or copied text, not a cleaned-up description) and returns a structured runbook in seconds: likely causes ranked by confidence, concrete next steps flagged by risk (safe to run vs. destructive), an escalation recommendation, and a draft status update. A second mode turns incident notes into a postmortem using the same "structure, not prose" approach.

Why I could build this

Four years of on-call and production troubleshooting at a Fortune 100 company across four SRE teams (Pulse system health, Datadog/BigPanda monitoring, incident response) means I know what a real runbook needs to contain, and where the generic version fails: unlabeled risk on suggested commands, causes that ignore the specific service, escalation guidance that's really just "ask someone else."

StackNext.js, Claude API, Supabase, Tailwind CSS, Vercel