Feature request: Deep Sentry integration for RCA and Real User Monitoring coverage

Problem

One important gap is real user monitoring. Coroot currently does not provide RUM as a feature set, but teams need visibility from the user/browser layer down to backend services and infrastructure to cover the full production stack.

Sentry already provides this missing user-experience and application context, including frontend errors, browser performance, affected users/sessions, releases, traces, and frontend-to-backend correlation.

Without an integration, teams have to manually switch between Coroot and Sentry during RCA and correlate this information themselves.

This is more than just a need for external links. The goal is to enrich Coroot’s RCA workflow with relevant Sentry signals, so Coroot can provide better context when a service or user-facing flow is unhealthy.

Proposal

Add a native Sentry integration that enriches Coroot service views, trace details, incidents, and RCA results with relevant Sentry data.

Coroot should be able to correlate Sentry data with Coroot entities using:

• service/application mapping
• environment
• release version
• deployment
• trace ID
• transaction name
• namespace/cluster
• labels or Kubernetes annotations

Expected behavior

When Coroot detects a problem, it should show relevant Sentry context directly in the RCA or service view, for example:

• new or regressed Sentry issues in the selected time range
• top exception/error groups
• affected releases
• affected users or sessions
• related Sentry traces
• frontend/RUM signals
• links to Sentry issues, events, traces, releases, and performance views

Example use cases

1. Application error RCA

A service shows elevated errors in Coroot. Coroot should show matching Sentry issues for the same service, environment, release, and time range.

1. Trace correlation

If a trace ID exists in Coroot, Coroot should show whether the same trace exists in Sentry and link to the Sentry trace.

1. Release regression detection

If Coroot detects a regression after a deployment, Sentry release data could show whether a new issue appeared shortly after that release.

1. RUM/user-impact enrichment

Coroot could show whether users are affected by frontend errors, slow page loads, Core Web Vitals regressions, or browser-specific problems detected by Sentry.

Suggested MVP

As a first iteration, the integration could start with:

• Sentry project mapping per Coroot service/application
• filtering by selected Coroot time range and environment
• showing related Sentry issues in the service and RCA views
• linking to matching Sentry issues and traces
• correlating by trace ID and release version where available

Requirements

• Support Sentry SaaS and self-hosted Sentry
• Configure Sentry base URL, organization, auth token, and projects
• Map Coroot services/applications to Sentry projects
• Filter Sentry data by time range and environment
• Correlate by trace ID and release version where available
• Show Sentry issues, traces, releases, frontend/RUM signals, and user impact in Coroot
• Prioritize new, regressed, frequent, or strongly correlated issues
• Handle missing mappings gracefully
• Respect permissions and avoid exposing Sentry data to unauthorized users

Why this matters

A deep Sentry integration would make Coroot more useful as a central RCA tool and help close the current RUM gap without requiring Coroot to build a full native RUM product.

Coroot would remain focused on service health, topology, infrastructure, Kubernetes context, and RCA, while Sentry would provide application errors, frontend/user-experience signals, releases, and traces.