Show HN: Watches user sessions, finds bugs that matter, and fixes them (github.com)
I’m Abhishek. I'm building Opslane, an open-source agent that identifies user-facing issues and investigates them. It only creates a PR if it can verify the fix.
Demo: https://youtu.be/ccuOTYQMeYg Docs: https://docs.opslane.com
At my last job at Robinhood, we used to do a quarterly bug bash. We would go through our Sentry backlog and try to fix as many of them as possible. We only fixed bugs we knew were reported by customers. We had hundreds of bugs, and Sentry’s default priority levels made no sense. After the bug bash, we would declare bankruptcy - select all remaining bugs and mark them as resolved.
This problem has only gotten worse since coding agents have become more prevalent.
So I started thinking: what would Sentry look like if it were built in 2026?
To me, error trackers have two failure modes:
1. False positives: They show you thousands of errors, and you can’t tell the impact on the user
2. False negatives: Many user-facing issues don’t throw exceptions, so they go unnoticed.
Opslane combines error tracking and session recording. And there is an agent that acts on both. To get started, you install the Opslane SDK. It captures everything the user did: errors, console logs, network requests, and session recordings.
Opslane reduces false positives by ranking issues based on how many users are facing a particular issue. It also learns about your product by reading your code and watching your session recordings.
False negatives are harder. Opslane reviews session recordings to spot frustration. They look for rage clicks, dead clicks, and abandoned forms.
This recently caught a bug in an early customer’s onboarding flow: a dropdown that closed itself when clicked. No exception, no bug report. The recordings showed users clicking it, selecting nothing, and dropping out of onboarding. Opslane flagged it and the team fixed it.
Three guiding principles when building Opslane:
1. Open Source: Self-host with one Docker Compose file.
2.Agent-first: I never want to open an error dashboard again. Opslane ships an MCP server, so you can ask "what broke for users this week" from Claude Code. You get back issues that need your attention and you drive the resolution.
3. It knows about your product: Opslane is continuously learning about your product. Every investigation begins with what it knows about your product.
It’s early. Frontend apps work end to end today.I am currently focused on improving reliability and accuracy.
Here is a link to our repo: https://github.com/opslane/opslane
Would love to get feedback from folks on our approach to this problem!
What does this mean in practice and how does it make your product better?
Update: I hope that didn't come across as a detraction; it's cool that you're building this. PostHog is open source, so if you haven't looked at their implementation yet, take a look, maybe it'll be useful to you!
The way the industry is normalizing a complete abandonment of user privacy absolutely boggles my mind.
And not only do you want to watch everything I do (note I don't care whether the scope is just your app or my whole screen), you want to ship that off to your partners who sell you tokens.
To anyone considering this tool my advice is simple: First take a hard look at your processes and consider ways to become better at actually listening to your users.
I've filed countless bug reports over time. Some companies handle them with efficiency and gratitude. But I'm saddened at how many large corporations just lose them to the void - in some cases it becomes clear nobody gives a shit - and in other cases, it's despite the apparent best intentions of their support staff and developers. Eg. After finally managing to get the attention of an Amazon exec rep, a website bug I reported found its way to a developer. The bug was confirmed and both seemed genuinely grateful, but for whatever reason the bug still exists today - many months later - despite several "it should be fixed now" turnarounds. I can only guess their processes for testing and deploying a fix are borked.
Could you address this with an AI bandaid? Maybe. But in nearly every case I've seen - and I've consulted for decades in this space - it's a symptom of corporate culture or business process. Start there.
Me as well, seems like we are losing that battle but I take the view I only lose when I stop fighting it.