Launching today
Superlog is an open-source autonomous observability tool. It installs itself and fixes the bugs it finds. With a single prompt, it instruments your repository with OpenTelemetry and keeps it up-to-date. When something breaks, it groups noisy issues into a single incident and posts one mergeable PR in Slack. Unlike Datadog or Sentry, there's no setup, no alert fatigue, and no manual fixing. Your telemetry stays vendor-neutral, so you keep full control of your data.
superlog
Hello ProductHunt! This is Arseniy, co-founder of Superlog.
The world is changing. We are building more and more stuff, and sometimes it breaks. And clicking through UIs to set up monitoring, or to find root causes of bugs is so 2024.
When I hear a PagerDuty alert at 3 am, I fumble around to find my phone and silence it before it wakes up the entire neighborhood. It usually takes me a few minutes to remember which century it is (Mammoths? Genghis Khan? Ah, right, 500s on prod).
We don't have to do this to ourselves.
That's why we built Superlog.
@arseniy_shishaev1 very cool Arseniy & congrats on the launch. I'd love more info on how you separate signal v noise to limit the 3am phone alarms
superlog
@zolani_matebese Great question! We have a suite of proprietary evals where we take an existing issue (the code and the telemetry) and run our agent on it. We then have ground truth values for the issue title / root cause / severity / patch and we use LLM-as-a-judge to check if our scores improve with every prompt change.
We run Superlog on Superlog too, so I frequently add new eval cases just based on what I see in our systems.
Our customers notice improvements in the prompt immediately (I was very surprised, and it feels great when 3 customers slack you saying 'yeah it's so much better')
Mention ✪ Insights Center
Superlog is a must have that we use at all the startups we are building at Hexa ! Strong recommend to give it a try, it's WOW !
superlog
@mvaxelaire thank you Matthieu! excited to empower the next generation of Hexa companies 🚀
superlog
@mvaxelaire appreciate!
Auto-instrumenting a repo with OTel via a single prompt is a sharp approach. The real trick is closing the loop from trace to mergeable PR. We've spent hours triaging alert storms where one upstream failure generated fifty distinct Sentry issues before the oncall engineer even saw the first one. How does the incident grouper determine causal relationships across services when the traces don't share a common parent span?
superlog
@anand_thakkar1 great question! that's exactly why we have the install prompt, it will add links between services (usually by adding a 'traceparent' header on your cross-service requests).
We also add nice things such as `session.id` which is a less known OpenTelemetry term. When you filter on session id, you can find all of the requests belonging to one page visit / app session :)
wowwww does it actually create the PR for me ? regardless of the severity of the issue ?
superlog
@michael_hodara1 100%! We give you a severity score (SEV1-3) for the bug (based on the user impact) and a full root cause analysis.
superlog
@michael_hodara1 Yep, but not for every issue.
Every incident starts with an investigation. The agent looks at logs, traces, metrics, code changes, and the execution path to understand whether there’s actually a bug worth fixing.
Most alerts end up being noise or issues where there’s not enough confidence to safely make a change. In those cases, no PR is created. That’s actually one of the core differences we’re trying to build: not “create a PR for every alert”, but first determine whether the alert deserves action at all.
Only when the agent concludes it’s a Severity 1 issue, it opens a merge-ready PR, shares it in Slack, and puts it in front of an engineer for review and merge.
Mailwarm
Where does the data actually go by default, like do you ship to your own collector or let teams plug in their existing stack?
superlog
@thamibenjelloun We store the data ourselves (yes, to our own collector)! Superlog can be plugged alongside an existing stack (Sentry / Datadog etc).
Storing the data ourselves allows us to query all data and do our own alerting and dashboards.
Polyvia
Make your product bug-free: Auto-instrumenting a repo with OTel from one prompt is impressive. How are you deciding what's worth tracing in a codebase the agent has never seen — is there a semantic understanding of the repo behind it, or mostly heuristics? Genuinely curious how deep the code comprehension goes.
superlog
@mateusz_gierlach great question! it is semantic: we're using your own agent, so it can launch subagents to add logs where they matter. In terms of the 'standard' of what needs to be added, we do:
logs on errors (so that you can page someone)
spans over all business operations (to know requests/errors/duration)
metrics on costs and performance dimensions
everything tagged by operation/endpoint, session id, user id, tenant/org id
the skills that instrument the repo are fully open source, check it out! https://github.com/superloglabs/skills
superlog
@sa206 we rely on OpenTelemetry SDKs to collect logs, metrics and traces - these are battle-tested open-source libraries.
They are designed to never block the client application and not to consume onbounded memory resources:
https://opentelemetry.io/docs/specs/otel/performance/
That being said, performance is important to keep in mind when sending logs, if it's a particularly tight loop, it sometimes doesn't hurt to move the observables out of that.