Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
11–20 of 60 posts
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#12I would love to try it but I got stuck when it asked for Slack since I dont use that.
Hm, sorry about that! I made the Slack onboarding step mandatory for now since we thought that a lot of our value was in sending investigations and PRs, and Slack was what we used ourselves. What tool do you use for communication around your project? If you don't want to share publicly, could you please shoot a line to: ash [at] superlog.sh? Would love to learn about your usecase in more detail too!
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#13Interesting project - but you need to add some information on where the data goes. As far as I can tell, code goes to some upstream ai provider (for installing, for analyzing). Telemetry goes to some provider or local hosted solution? And then to your upstream ai provider for analysis?
When you're installing Superlog, you can use any coding agent you'd like, including a local model.
Your telemetry then goes into our data stores, and right now we have one DC on the US west coast.
Whenever there's an error log or trace, Superlog can analyze it and prepare a resolution PR (or a note if something needs to be done manually).
This can be turned off and then the incident can be sent to your own models via a webhook.
We use one of the frontier models for that (it's an upstream AI provider). We're working on our own fine-tuned version of a SoTA model to minimize dependency on other AI providers.
To investigate an incident, we clone the repo in our worker, and pass the repository files to a coding agent in a sandbox. The agent has an MCP that gives it access to the telemetry (logs/metrics/traces) of the project.
The coding agent will then investigate the incident and prepare a patch. It hands over the patch via a tool. The worker then deterministically pushes the patch to a branch and opens the PR.
This way the agent doesn't have full Git access and can't do anything it's not supposed to do in the repository.
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#14That been said for more complex setups like on kubernetes where you need a collector and an operator I found OTEL to be super painful to setup a couple of years ago. Has it gotten any easier now?
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#15I would love to try it but I got stuck when it asked for Slack since I dont use that.
Hm, sorry about that! I made the Slack onboarding step mandatory for now since we thought that a lot of our value was in sending investigations and PRs, and Slack was what we used ourselves. What tool do you use for communication around your project? If you don't want to share publicly, could you please shoot a line to: ash [at] superlog.sh? Would love to learn about your usecase in more detail too!
For my current project I would use webhooks/email just like I do currently for my monitoring and alerting.
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#16Earlier quoted context omitted.
Hm, sorry about that! I made the Slack onboarding step mandatory for now since we thought that a lot of our value was in sending investigations and PRs, and Slack was what we used ourselves. What tool do you use for communication around your project? If you don't want to share publicly, could you please shoot a line to: ash [at] superlog.sh? Would love to learn about your usecase in more detail too!
I don’t use Slack either. What about solo indie founders who don’t use “team communication”?
The platform itself doesn't need Slack to function, we just observed that users got more value if they could get notifications somehow, so I'm more than happy to add more comms platforms :)
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#17The moment something changes the system, it no longer observes it, in fact observing something might cause it to change ( https://en.wikipedia.org/wiki/Observer_effect_(physics) )
Either it's a tool for observing or it's a tool for fixing issues, it cannot be both, by physical principle.
Best case scenario here is that the product succeeds, and then you need to instrument the product itself in order to observe it, like debugging the debugger. But it wouldn't be an observability tool, it would shift the product that needs to be observed from the previous source code that is now a target language into the new source code that is now your product.
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#18Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#19> Start with one repo. Price the rest when the signal is real.
which makes it sound like possibly the $150/mo price is per-repo?
I think that could use some clarification - if I have 10 services in a monorepo vs 10 individual service repos, does that 10x my cost?
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#20It's something we've thought a lot about at Amplitude. We'd love to talk.