Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
Source: Hacker News
Introduction
Hey HN, we’re Nico and Arseniy, co‑founders of Superlog (https://superlog.sh). We’re building a self‑installing, self‑healing observability tool that aims to work without manual intervention. It includes a wizard that daily sets up proper logging and an agent that investigates errors and opens PRs.
Demo
Super short demo: https://www.youtube.com/watch?v=xFhU9Mk247M
The Problem
In our earlier startups we tried Sentry, Datadog, Grafana, Dash0, and nothing was good enough. Proper telemetry and alerting still required a lot of manual setup. Adding good logs was hard, making debugging tough as codebases grew quickly. Meanwhile, the Datadog/Dash0 bill kept climbing, and we still spent engineering hours learning, configuring, and maintaining our observability tooling.
- With Sentry we were flooded by duplicate alerts lacking context, leading to alert fatigue and constant interruptions—especially painful on a Saturday morning.
- Servers often ran out of memory or disk, and three AWS metrics gave three different values.
- Many dashboard graphs were empty or outdated, and manually clicking through UIs was a huge waste of time for small teams.
We realized that solving this problem would be more valuable than the things we had been working on, and we had the expertise to do it—Arseniy spent years at Datadog, getting paged at night to debug production incidents. So we decided to build a platform that would just work: agent‑first, MCP‑native, zero‑setup.
How Superlog Works
- Wizard – Scans your repository and automatically instruments it with well‑structured logs, traces, and metrics via OpenTelemetry. It highlights main failure modes, endpoint performance, usage per tenant, and LLM/upstream cost (by call‑site, tenant, and model).
- Error Fingerprinting – Errors are fingerprinted and grouped into incidents, so you see one issue instead of thousands of duplicates. Notifications include a clear failure summary, inferred severity, and impact.
- Agent Investigation – The agent investigates each incident.
- If it has enough context, it produces a concise, tested PR.
- If not, it posts its findings for the investigating team and automatically pulls in engineers who could contribute more context based on documentation, previous investigations, and Slack threads.
In either case, the output is one clean PR per incident, posted in Slack, that you can merge, ignore, or open as a Claude Code session and modify.
Key Differentiators
- Zero‑Setup Instrumentation – The wizard instruments everything with native OTel SDKs, respecting semantic conventions and proper service/environment tagging. We’re also building native automatic dashboards and alerts for instant visibility.
- Telemetry That Doesn’t Decay – The wizard runs daily, continuously adding logs, alerts, and dashboards where needed. You don’t have to remember to instrument new features; the data you need is already there when something breaks.
- Alert‑Fatigue Reduction – Agents merge similar errors and refine summaries, providing relevant information upfront. A custom evaluation setup ensures summaries are dense and correct, with accurate severity and impact. Confidence scores are provided for every LLM‑enhanced metric to prevent boosting wrong guesses.
Pricing & Availability
Superlog telemetry is vendor‑neutral, so you keep all the logs, metrics, and traces we install. Pricing details are on the site. We’re early, so expect rough edges—please let us know when you find them.
You can try it at https://superlog.sh.
Call for Feedback
We’d love to hear:
- What you’re using today
- What’s broken about it
- Whether the “one mergeable PR per incident” model sounds useful or terrifying
Especially keen to hear from folks running integration‑heavy products, anyone who’s rolled their own observability, and anyone who has tried Sentry / Datadog MCPs and given up. Comments and feedback welcome!
Comments URL: https://news.ycombinator.com/item?id=48195021 (Points: 19, Comments: 14)