Relvy AI, a Y Combinator Fall 2024 company, has launched a platform that turns plain-language on-call runbooks into AI-assisted incident investigations. The pitch is aimed at engineering teams that already rely on observability tools, alerts and runbooks, but still lose valuable time when production systems fail and humans have to gather context across dashboards, logs, traces and code.
The company describes the product as an AI-powered debugging notebook for incident response. Instead of asking an engineer to paste logs into a general-purpose chatbot, Relvy connects to observability systems, follows runbook steps and records the investigation in a reviewable notebook. That audit trail is the most important part of the story: production incident response is not a place where a black-box agent can simply guess and move on.
Why runbooks are a useful boundary for AI
Runbooks are the operational memory of an engineering team. They tell responders what to check first, which dashboards matter, which services usually fail together and when an issue should be escalated. Relvy’s approach is to let AI execute those human-written steps, rather than letting an agent wander freely through production systems.
That design choice matters because autonomous root-cause analysis remains difficult. In a Hacker News launch post, Relvy argued that current models struggle with three things: too much telemetry noise, company-specific context and the time pressure of on-call work. A wrong AI suggestion during an outage is more costly than a bad autocomplete in a code editor.
What the product actually does
According to Relvy’s public materials and GitHub repository, the system can query logs, metrics, traces, dashboards and code while following markdown-style runbooks. It supports integrations such as Datadog, New Relic, Grafana, Elastic and PagerDuty, and then presents the findings in a notebook with charts and evidence for human review.
The open trial deployment is careful about safety. Relvy says the AI can investigate and recommend actions, but human approval is required before touching production. That human-in-the-loop requirement is not a minor feature. It is what separates a potentially useful incident assistant from an unsafe automation layer that might restart services, change configuration or hide the real cause of an outage.
The benchmark claim needs context
Relvy has also published benchmark material around OpenRCA, a dataset for root-cause analysis in distributed systems. The company says Claude Opus 4.6 scored 36 percent accuracy on the dataset and that its own harness improved performance by 12 percentage points in that setting. Those numbers are useful as a signal, but they do not guarantee that the product will solve half of a company’s real incidents.
Production environments are unique. Naming conventions, historical incidents, deployment habits, undocumented dependencies and business priorities all shape what “root cause” means inside a particular team. A benchmark can show that structure helps the model reason better; it cannot replace testing the tool on real alerts under the governance rules of the company using it.
Where Relvy fits in the incident-response market
Relvy is part of a wider wave of engineering tools trying to turn AI from a coding assistant into an operations assistant. The opportunity is clear: on-call work is stressful, repetitive and expensive, and the first minutes of an incident are often spent collecting evidence rather than making decisions. If AI can reduce that collection phase, teams may resolve incidents faster and with less burnout.
The risk is equally clear. Incident response is high-stakes, and the cost of a confident but wrong diagnosis can be severe. Relvy’s strongest positioning is therefore not “AI replaces the on-call engineer.” It is “AI prepares a structured, auditable investigation so the engineer can decide faster.” That is a narrower claim, but it is also a much more credible one.
For engineering leaders, the practical question is not whether an AI agent can debug everything. It is whether a runbook-driven assistant can make the first 10 or 20 minutes of response more consistent, better documented and easier to hand off. If Relvy can prove that in real production environments, its value will be less about hype and more about operational discipline.
