Yes exactly! The purpose isn't to create one PR per alert—that would just move noise from one place to another. The bottleneck we're solving is triaging: cutting the noise and turning it into signal. Once we've done that, we fix issues and show you a PR.
I think it works well because we have two deduplication steps and we group based on RCA—both before and after Claude Code analysis.
Severity also helps cut noise by highlighting which problems/solutions to review first. It's easier when the issue comes from a frontend trigger, but many alerts come from backend errors only. In those cases, Claude Code assigns severity based on its understanding of how a broken feature blocks product usage.
It's hard to make it simple. the complexity is on our side, but our goal is to cut the noise from production alerts so we're removing complexity rather than adding it.
Interesting. it makes sense that it depends on the number of alerts you receive. but I’d think that if 70% of the PRs you receive are noise, an AI triager could be useful—if you give it the context it needs based on your best practices.
I’m very curious about the kinds of manual intervention you do on PRs when one is required. What does the follow-up prompt look like? Is it because the fix was bad, because the RCA itself was wrong, or because of something else?
totally get the 'token wastage' point—sending noise to an LLM is literally burning money.
but an other maybe bigger cost might be your time reviewing those 'bandaid fixes.' if you're merging only 30%, that means you're spending 70% of your review bandwidth on PRs that shouldn't exist right?
we deduplicate before the claude analysis with the alert context and after based on the rca so we ensure we have no noise in the PRs you have to review
why don't you trust an agent to triage alerts+issues?
We don't have plans to open-source the platform yet, but we prioritize transparency. For example, we display all tool calls and system prompts to help developers verify the RCA immediately.
Regarding the open-source projects—are you referring to rrweb and the Sentry SDK? We used them for the first version of our product, but we’ve since switched to connecting directly via OAuth and native integrations.
To avoid this 'busy work', we group alerts by RCA (so no duplicate PRs) and filter by severity (so no PRs for false positives or not-that-important issue). We realized early on that turning every alert into a PR just moves the problem from Sentry to GitHub, which defeats the purpose.
Is having a one-hour cron job enough to ensure the product’s health? do you receive alerts by email/slack/other for specific one or when a PR is created?
hey thanks for the feedback! After the onboarding, we process your last issues to show you the triage and analysis, it works only if you have past alerts. do you have alerts in sentry?
we have a bot Slack feature to be inside their workflow so they don't have to go check the dashboard
I think it works well because we have two deduplication steps and we group based on RCA—both before and after Claude Code analysis.
Severity also helps cut noise by highlighting which problems/solutions to review first. It's easier when the issue comes from a frontend trigger, but many alerts come from backend errors only. In those cases, Claude Code assigns severity based on its understanding of how a broken feature blocks product usage.