Set up Sonarly – AI Production Alert Triage

TL;DR

TL;DR: Sonarly is a YC W26 AI agent that plugs into your existing observability stack (Sentry, Datadog, Slack) to automatically triage production alerts, surface root causes, and propose fixes — cutting MTTR without changing your monitoring setup.

Source and Accuracy Notes

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

• Project page: sonarly.com
• HN launch thread: news.ycombinator.com/item?id=47049776
• License: Proprietary (no open-source license detected; core product is SaaS)

What Is Sonarly?

Sonarly is an AI engineer for production. Rather than replacing your existing observability tools, it sits above them and acts as an intelligent triage layer. When an alert fires, Sonarly:

1. Ingests alerts from Sentry, Datadog, Slack user feedback, and other integrated channels
2. Groups duplicates to cut through the noise — dozens of identical errors collapse into a single actionable item
3. Returns root cause analysis in plain English, explaining the “what,” “why,” and “how to fix it”
4. Proposes code fixes directly, drawing on full runtime context from your observability stack

The founding story (per the HN launch) is relatable: the team ran a B2C edtech app with thousands of daily users, pushed several times a day, and found themselves drowning in up to 50 Sentry alerts per day with only two engineers. They built Sonarly to solve their own alert fatigue.

Setup Workflow

Step 1: Connect Your Observability Stack

Sign up at sonarly.com and authorize the integrations you already use. The currently documented integrations include:

• Sentry — error tracking and session replay
• Datadog — metrics, traces, and APM
• Slack — user-reported bugs from feedback channels

Installation does not require replacing your existing SDKs or trackers. Sonarly reads from your existing data rather than ingesting its own agent.

Step 2: Configure Alert Routing

Point Sonarly at the alert sources you want triaged. You can scope it to specific projects or environments.

Step 3: Review AI-Triaged Output

When an alert fires, Sonarly processes it through its context engine and surfaces a structured summary. The output is designed to be readable without opening Sentry, Datadog, or any other dashboard.

Deeper Analysis

Why Triage Matters More Than Detection

Most observability tooling excels at detection but delivers alerts unfiltered. A production incident typically generates multiple signals across different systems — error rates in Datadog, individual error instances in Sentry, user reports in Slack. The noise-to-signal ratio for on-call engineers is high, especially in smaller teams.

Sonarly’s value proposition is reducing Mean Time To Repair (MTTR) by handling the triage step that historically requires an engineer to manually correlate signals across tools.

Claude Code Integration

The founders note that while Claude Code is highly capable for code writing, handling runtime issues requires more than raw coding ability — it demands deep runtime context, immediate reactivity, and intelligent triage. Sonarly is designed to provide that runtime context so AI coding agents can act on production issues with full understanding of what went wrong and where.

Session Replay Basis

Sonarly’s frontend tracker is based on the open-source rrweb project for session replay. The backend uses the Sentry SDK (open source) for data collection. This means the underlying data capture is auditable and standards-compliant, even if the triage layer itself is proprietary.

Practical Evaluation Checklist

• Connects to existing Sentry and Datadog without replacing current monitoring
• Groups duplicate alerts to reduce noise per incident
• Returns root cause summary in plain English
• No SDK replacement required for most integrations
• Based on open-source rrweb for session replay
• YC W26 backed (verified via HN launch thread)

Security Notes

• Alert data is processed through Sonarly’s cloud infrastructure — verify your data handling requirements with their privacy policy before connecting production systems
• Session replay data can capture user interactions; confirm scope aligns with your privacy compliance requirements (GDPR, CCPA, etc.)
• The tool requires read access to your observability data; use least-privilege credentials where your monitoring stack supports scoped API keys

FAQ

Q: Does Sonarly replace Sentry or Datadog? A: No. Sonarly reads from your existing Sentry and Datadog data. It is a triage and analysis layer on top of your current stack, not a replacement.

Q: What happens to my alert data? A: Alert and session data is processed through Sonarly’s servers. Review their privacy policy for retention and handling details specific to your compliance requirements.

Q: Is the code fix actually safe to apply automatically? A: Sonarly proposes fixes with full runtime context, but any automated code changes should be reviewed before deployment. Treat proposed fixes as suggestions backed by analysis, not as auto-deployments.

Q: Does it work for small teams? A: The founding team originally built the tool for a two-person startup drowning in daily alerts, so it is specifically designed for teams without dedicated SRE staff.

Conclusion

Sonarly solves the alert overload problem for developers who already have solid observability tooling but lack the bandwidth to manually correlate every signal. By connecting to Sentry, Datadog, and Slack without requiring a new SDK, it delivers root cause summaries and fix proposals in plain language — letting engineers focus on building rather than triaging.

If you are running a lean team and spending significant time each day filtering monitoring noise, Sonarly is worth evaluating. The YC W26 backing gives it a degree of institutional credibility, and the rrweb-based replay layer means the underlying data capture is transparent.

Next steps:

• Visit sonarly.com and connect your first integration
• Read the HN launch thread for the full founder story