by eddy-sekorti
0 subcomment
- Congratulations with the launch and it looks good, do you provide any API for other tools to integrate superlog.
- Not their fault
Railway their hosting provider is entirely down as well
From https://status.railway.com/
>Identified
>Google Cloud has blocked our account, making some Railway services unavailable. We have escalated this directly with Google. The Railway Platform team has since confirmed access to Google Cloud and is working on restoring access to all workloads. We have access to some of our Google Cloud–hosted infrastructure and are working to restore the rest of the service. We apologize for the disruption.
by OsrsNeedsf2P
1 subcomments
- There's very few startups that I look at these days and don't think to myself, "I could just write a Claude skill for that". This one seems pretty cool. Congrats on launch
- >> 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.
by jonnyasmar
1 subcomments
- Building on the "investigation > patch" point — running Claude Code, Codex, and Gemini CLI daily, the pattern I keep noticing is that auto-fix is fine on "obvious bug, obvious fix" (off-by-one, null check, missing await, error not propagated). It falls over on "subtle invariant" bugs where the existing code is intentionally weird to preserve something non-obvious — the PR looks right and breaks something three modules away.
The tool I'd actually want isn't "tries harder to fix everything." It's one that credibly says "this touches an invariant I can't see — here's what I think might happen, you handle it." Calibrated humility beats confident patches.
Curious how your high-confidence threshold actually works. Self-reported model certainty (notoriously unreliable), test coverage in the affected area, blast-radius of the change, something else?
- I would love to use it but the website is down
"Please check your network settings to confirm that your domain has provisioned.
If you are a visitor, please let the owner know you're stuck at the station."
Would love to learn more and consider being a customer!
- Interesting 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?
- investigation is the hard part, not generating patches. we've had prod issues where the fix was obvious once you knew the cause, but finding the cause meant connecting an error trace to a config change from 3 deploys ago. if the MCP only surfaces traces and logs from one service the agent is going to propose workarounds instead of actual fixes. how deep does the investigation context actually go?
by tommy29tmar
0 subcomment
- Before running the install prompt, I’d want to see a dry run: which files it would touch, what telemetry leaves the box, provider calls, and what “high confidence” means. For debugging tools, generating a PR is the easy part; knowing whether it’s grounded in enough evidence is the part I’d worry about.
by 0xferruccio
1 subcomments
- Congrats on the launch, this looks very promising. I hadn't seen any installation that uses a URL to point to a skill, seems like an evolution of wizard scripts
That 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?
- I love the launch! Automated observability that feeds back into the product development process is the future of this category vs having to spend a lot of time configuring and managing the infrastructure yourself.
It's something we've thought a lot about at Amplitude. We'd love to talk.
- It deleted the codebase, which technically.. is a valid way to get rid of all of the bugs.
I kid, nice work. As others have said, investigation, and understanding "the why it was originally done that way", not the patch, is usually the lion share of the work.
- Love the concept! Some feedback: I went to sign up to give it a go, but the set up process left me feeling a bit untrusting - so I backed out for now. I'd prefer more explanation about what to expect, what I will get, how it is safe, etc before asking me to run a prompt.
- I would love to try it but I got stuck when it asked for Slack since I dont use that.
by evil-olive
1 subcomments
- on your pricing page:
> 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?
- Seems very useful, congratulations on the launch!
- Any plans for an on-prem version?
by FantasyLabai
1 subcomments
- This is a very interesting idea and im excited to see where this goes. Congrats!
by tontinton
1 subcomments
- What's your moat?
by aloknnikhil
1 subcomments
- The typical issues I have seen with LLMs / Agents tend to be reactive in their fixes. So they tend to "patch" the symptom more than "fix" the root cause. Interested to see how you solve this problem.
- Sorry to be crude, but this sounds either dead on arrival, or at least needing a pivot, or a rephrasing of the pitch:
The 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.
- [dead]
- [dead]
by Ember_Wipe
1 subcomments
- [flagged]