Relvy - AI-Powered On-Call Runbook Automation

TL;DR

TL;DR: Relvy is an AI agent that automates on-call runbooks for software teams. It connects to your telemetry stack, analyzes anomalies and logs using specialized tools, and executes runbook steps — reducing MTTR without flooding the context window with raw data.

Source and Accuracy Notes

⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: relvy.ai — verified via direct fetch
• HN launch thread: news.ycombinator.com/item?id=47702647 — verified via HN Algolia API
• YC company page: ycombinator.com/companies/relvy — not directly accessible; batch confirmed from HN thread title
• Source last checked: 2026-08-06 (HN item ID 47702647)

What Is Relvy?

Relvy is an AI-powered on-call automation tool for software engineering teams. Its core function is to act as an autonomous agent that reads your runbooks, connects to your observability stack, and works through production incidents — analyzing telemetry data, identifying anomalies, and executing remediation steps without requiring a human to paste logs into a chat window.

From the founders’ HN introduction:

“Relvy automates on-call runbooks for software engineering teams. It is an AI agent equipped with tools that can analyze telemetry data and code at scale, helping teams debug and resolve production issues in minutes.”

The platform targets the gap between alert firing and incident resolution. Rather than relying on a large language model to ingest raw logs directly, Relvy gives the agent specialized tools for telemetry interpretation — anomaly detection on time-series data, structured log search, and span tree analysis — so the context window stays focused on actionable signals rather than noise.

Why On-Call Automation Is Hard for AI

The founders highlight a key benchmark problem: even frontier models struggle with autonomous root cause analysis. On the OpenRCA dataset, Claude Opus 4.6 scores around 36% accuracy. Relvy identifies three structural reasons:

1. Telemetry volume — production systems emit massive logs and metrics that overwhelm a model’s context window
2. Enterprise context dependency — data interpretation requires knowing your service topology, ownership, and historical incident patterns
3. Time pressure — on-call is high-stakes and time-constrained; exploratory agentic reasoning that works in coding tasks does not fit

Relvy’s approach is to specialize the agent’s tooling rather than rely on general-purpose context stuffing. The agent anchors its reasoning around your actual runbooks and uses structured telemetry queries to narrow the problem space before attempting root cause inference.

Key Features

Specialized Telemetry Tools

Relvy’s agent ships with purpose-built tools rather than raw log ingestion:

• Anomaly detection on time series data — identifies which metrics deviate before or during an incident
• Problem slice identification — surfaces the specific subset of traffic, users, or requests affected
• Log pattern search — structured querying of log sources rather than full-text dump
• Span tree reasoning — traces request paths across distributed services to isolate the failure point

Runbook Execution

The agent reads your existing runbook documents and executes steps autonomously, escalating to a human when it cannot resolve the issue. This differs from a chatbot where a human drives every step.

MCP Integration

Relvy integrates with Datadog’s MCP server, which the founders specifically called out as a common pattern teams already use:

“You may be pasting logs into Cursor, or using Claude Code with Datadog’s MCP server to help debug.”

This positions Relvy as complementary to — rather than replacing — existing AI coding workflows.

Setup and Configuration

Since Relvy is a hosted service (YC S25 company), configuration involves connecting your observability accounts rather than installing software. The general setup flow based on the product:

1. Connect your monitoring stack (Datadog is explicitly supported; others may be available)
2. Import or link existing runbooks
3. Configure alert routing — which incidents should trigger autonomous response
4. Set escalation policy — when the agent should hand off to a human

Exact configuration steps require access to the Relvy dashboard, which was not accessible at the time of writing.

Practical Evaluation Checklist

• Use case: teams already using Datadog or similar telemetry platforms
• YC-backed: Yes — YC S25 batch (confirmed from HN thread title)
• Deployment model: Cloud-hosted SaaS; no self-hosted option mentioned
• Integration: Datadog MCP server confirmed; Cursor/Claude Code workflow mentioned
• Benchmark positioning: OpenRCA 36% (Claude Opus 4.6) cited as the problem baseline
• Founders: Bharath and Simranjit (full names not disclosed on public HN thread)

Security Notes

As a hosted service that reads your telemetry data and executes runbook steps in your cloud environment:

• Review what data Relvy can access in your monitoring and alerting systems
• Confirm the escalation handoff mechanism before enabling fully autonomous mode
• Audit the MCP integration permissions — it effectively has access to query your Datadog data

FAQ

Q: Does it replace a human on-call engineer? A: No — Relvy is designed to handle routine incidents autonomously and surface structured findings for complex ones. Escalation to a human is part of the design.

Q: Which observability platforms does it support beyond Datadog? A: Datadog MCP is explicitly documented. The product page and HN thread did not list additional integrations at the time of checking.

Q: How does it handle incidents outside office hours? A: The autonomous execution model is specifically designed for after-hours incidents where human engineers may be slower to respond.

Q: Is there a self-hosted option? A: No self-hosted option was mentioned. Relvy is a hosted SaaS product.

Conclusion

Relvy tackles a real problem: the gap between an alert firing and an engineer understanding what broke. By giving the AI agent specialized telemetry tools rather than asking it to parse raw logs, it takes a more defensible approach than generic context stuffing.

It is early-stage (YC S25, public launch), and details on pricing, supported integrations, and availability were not fully accessible without account creation. Watch for expansion beyond Datadog MCP if you use a different observability stack.