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.
@arseniy_shishaev1 The “which century is it” disorientation at 3 AM is the most accurate description of incident response I’ve ever read. I once spent twenty minutes staring at a dashboard trying to correlate two metrics, only to realize I was looking at staging because my brain hadn’t fully booted yet. The cognitive tax of debugging while half-asleep is real, and it’s rarely accounted for in tooling.
Building monitoring that meets you where your brain actually is at 3 AM, not where it should be, feels like the kind of empathy-driven engineering that prevents burnout as much as it prevents downtime. Congrats on the launch.
superlog
@diana_nadim2 Thank you Diana! Super happy it resonates :) Don't hesitate to give Superlog a try!
an agent that groups noisy alerts into one incident instead of pinging you 50 times is already worth it. the auto-fix PR on top of that is the part that would've saved our dev team so many 3am debugging sessions
superlog
@tina_chhabra would be happy to take care of it now!!