SREs hate writing runbooks because they know the runbook will be wrong. Here's how to fix that.
Every SRE I've talked to has the same story. 3am incident. You pull up the runbook. Step 4 assumes the database is reachable. It isn't. The runbook is now a historical document and you're improvising.
The runbook wasn't bad because the person who wrote it was careless. It was bad because there's no feedback loop between "runbook written" and "runbook fails during incident." You write it once, file it somewhere in Confluence, and find out it's broken the worst possible way.
That's the problem this idea is solving. And I think it's actually buildable in a weekend (or five weeks if you want something shippable).
The pitch is simple: upload your incident post-mortems, get a structured runbook out, then have the tool automatically generate edge-case scenarios from your own incident history and walk them through the runbook logic to find unhandled branches.
The output isn't a chat interface. It's a gap report: here are the decision paths in your runbook that no test scenario ever reached, here's a missing rollback step in branch 3B, here's a scenario where your rollback procedure assumes write access you might not have.
The aha moment lands fast. Someone uploads a real PagerDuty transcript, sees a structured runbook in 60 seconds, and then sees the gap report flag a missing rollback step they actually remember from a past incident. That's when it clicks.
Here's the validation approach I'd run first, and it's genuinely useful even if you never build the product.
DM 20 SRE leads on LinkedIn. Not generic cold outreach. Find people who have posted about on-call toil, whose bios mention post-mortems or incident response. Tell them you're running a "runbook audit" service: they send you their incident post-mortems (Slack exports, Confluence pages, PagerDuty timelines), you use GPT-4o to generate a structured runbook and then manually write 10 edge-case scenarios, and you walk through the gaps on a 30-minute call.
Charge $500 flat for the audit report.
You're not automating anything yet. You're doing it by hand to see if people will pay and if the output is actually useful. Your success metric: 3 out of 5 pilot customers say they found a gap they wouldn't have caught otherwise, and at least 2 say they'd pay $200+/month for an automated version.
If you hit that, build. If you get "this is interesting but not worth $500," something is wrong with the value prop and you want to know that before spending five weeks coding.
Post in r/SRE asking for beta testers too. The SRE community is extremely opinionated and will tell you exactly what they think is wrong with your approach, which is painful but useful.
Next.js, Supabase, OpenAI API, Stripe. Deploy on Vercel. PagerDuty OAuth for data ingestion. That's it.
The build breaks into three parts:
Weeks 1-2: File upload for incident transcripts (text, PDF, Slack export JSON) plus PagerDuty OAuth. Pipe the transcript through GPT-4o with a prompt that extracts a structured runbook with explicit decision branches. Store the runbook in Supabase. This is the boring part but it has to be solid.
Weeks 3-4: The scenario engine. This is where it gets interesting. Extract failure patterns from the incident history using embeddings, cluster them, and generate test scenarios that walk the runbook's decision tree. You're not running real infrastructure. You're walking the logical decision tree and annotating which branches are never reached, which steps have missing precondition checks, which rollback paths are undefined. The output is a structured annotation, not a live test.
Weeks 5-6: Gap report UI. An annotated runbook view showing tested vs. untested paths, severity-rated gaps, and a "refine" button that re-prompts the LLM with the gap context to produce an updated runbook draft. Stripe billing.
One thing I'd add on day one: a "local mode" where the transcript processing runs via a browser-side call to the customer's own OpenAI API key. Nothing leaves their environment. This is maybe two days of work and it removes the #1 objection from security-conscious teams before they even raise it.
A lot of people will look at this and say "you're just wrapping GPT-4 and calling it fuzzing." That's a legitimate concern and it will come up on Hacker News. The generation piece is not defensible. PagerDuty or incident.io could ship LLM runbook generation tomorrow.
The defensible part is the scenario library. As teams ingest more incidents, the embedding clusters get more specific to their environment. After six months, a team has a corpus of failure patterns that's genuinely proprietary. Their test scenarios aren't generic chaos templates. They're interpolations between their own real failure modes. A new tool can't replicate that without their full incident history.
That's why the fuzzing layer is where you should spend your engineering attention. The generation is a hook. The gap report quality over time is the moat.
I want to be straight about the things that could sink this.
The fuzzer tests runbook logic, not live infrastructure. Some SRE practitioners will immediately say that's not real testing, that real incidents involve environment-specific surprises no text-based simulation can catch. If your first 10 beta users say "this is just a fancy linter," you have a serious problem. You'd have to build a live infrastructure test harness, which adds months and introduces security objections that are much harder to handle.
There's also a timing problem with sales. The moment someone wants a better runbook is right after an incident. That's when the pain is fresh. But the buying decision usually happens weeks later when urgency has faded. Your free-to-paid conversion window is longer than you'd expect, which means more nurturing, more follow-up, and a slower revenue ramp.
And the buying champion is fuzzy. SRE leads at 100-person companies often don't have their own budget. It's too technical for an engineering manager to approve without understanding it, too operational for a developer to expense personally. You need to find the person with both the technical credibility to evaluate it and the budget authority to buy it. That person exists, but you'll spend time figuring out who they are.
Free tier: 1 runbook/month, 5 test cases. No credit card required.
$49/month Starter, $149/month Team (unlimited runbooks, Jira and Slack integration), $399/month Pro. You need 18 customers on the Team plan to cover basic expenses including a modest founder salary.
For the first 10 customers: post a 3-minute Loom showing a real PagerDuty transcript becoming an annotated runbook in r/SRE and r/devops. Run a Show HN post. Search Twitter and conference talk abstracts from SREcon for people who have publicly complained about runbook quality and reach out directly. These people already know the pain. You're not convincing them the problem exists.
The r/SRE community has about 200K members and a high signal-to-noise ratio. A genuine tool posted without marketing language will get honest feedback. That's what you want.
The combination that doesn't exist yet is LLM-based generation plus automated fuzzing against those runbooks plus a gap report that closes the loop. PagerDuty has runbook features. Confluence is a static repository. Gremlin does chaos engineering but doesn't connect results back to runbook quality. Nobody has put these together.
The market is real but bounded. About 15,000 SRE teams in the 50-500 engineer range are the real target. At $300/month average ARPU, you're looking at a clean $5-10M ARR bootstrapped business. That's not a venture-scale outcome. It's a very good independent software business.
If you're an indie hacker who wants to build something SREs will actually use rather than another AI wrapper, this one has teeth. The pain is documented and real. The validation path is concrete. And you can build the MVP in five weeks with tools you already know.