Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs

Great question! The investigation agent has access to all the telemetry - not only one service. So we can actually trace the root cause in such complex cases!

There are good ways to link operations between different services with OpenTelemetry (for example, passing the parent trace id in an inter-service HTTP/gRPC request). It's a bit tedious to do by hand, that's why we're publishing the skill that does that for you.

And totally agreed on config changes and deploy info. We've seen that having good environment and version control (commit hash, file name, line number) tagging is extremely important for root cause analysis, so we go hard on this in the skills.

We also have many infra integrations in our roadmap to make sure that we can deeply analyze the infra/config side of things.

Good question! We don't have one as of today, just because we're iterating very quickly and a cloud version is the quickest way for us to keep things lean and up-to-date, but we're not far from having one.

Could you please send me an email at ash [at] superlog.sh? I'd love to hear more about your use case - we might have something for you very soon!

Great question! I like to think about this in two ways:

1. Counter-positioning. Most existing tools have invested heavily in their web platforms and compete on their UI/UX. But actually, what matters to our clients is that bugs are fixed. Our top clients would rather never open our tool at all. If our competitors want to beat us, they essentially have to fight against their established business models that hinge on users looking at their browsers.

2. Evals. In order to have the most accurate RCA analysis you need a very good suite of evals: what was the right root cause in this bug? what is the right fix?. We're investing into this heavily, and as one of the early movers we have a big advantage here.

At the same time, I tend to approach strategy with a lot of caution. A lot of the canonical reasoning behind 'startup positioning' is based on extrapolation from trends, but surprisingly few analogies work in economics.

Our focus right now is: - talking to our users - making sure they have the best experience

>> Superlog scans your codebase and infrastructure to add new alerts, metrics and dashboards, preventing tricky failure modes and observability decay.

This is interesting, and my prior belief here has been that this automates a one time set up, and perhaps a quarterly clean-up or reactive monitoring changes that people do today. Curious what your experience has been - do teams accept these ongoing maintenance PRs at a good rate?

For full disclosure / context: we work in a related space - investigation agents for production issues.

Interesting product, but had similar question, i think it will take a little time to be mature for production systems: as what i can see right now is very straightforward, most of the observability providers are doing this, in case you already have the observability stack setup. we currently use Openobserve they have an ai agent that provides correlation, cause and fix for any issues . The real differentiator can be on how accurately you can do the investigations, and how brutally you can steelman the ability for it locate the issue, cause and fix. Good luck on the launch