Sentry

Connect Sentry when bug investigations depend on real error, alert, or performance context from production.

​

When to use it

• Investigate an error without manually copying stack traces and issue history
• Connect production evidence to the repository work that should follow
• Answer whether an issue is widespread, recent, or tied to a specific release

​

How setup works

Admins connect Sentry once from Settings > Integrations. Sentry’s consent screen lists four access groups, all selected by default:

• Inspect Issues & Events is read-only: issues, events, traces, replays, releases, monitors, profiles, documentation, and project metadata.
• Seer, Triage Issues, and Manage Projects & Teams grant write access: AI analysis runs, resolving and assigning issues, and creating or editing projects, teams, DSNs, and uptime monitors.

Roomote does not restrict the connection beyond what you approve there. For a read-only connection, leave only Inspect Issues & Events selected. You can also disable individual tools afterwards from the integration’s tool settings. Most Sentry operations run through the execute_sentry_tool gateway, so disabling that tool removes the whole catalog rather than a single operation.

​

What to expect

Sentry gives Roomote incident and performance context during a task. It can also support scheduled Sentry triage. The final decision, code change, and review still happen in the normal task and repository flow. Roomote agents are instructed to treat Sentry as read-only unless a request explicitly asks them to change Sentry state. That instruction is not enforced by Roomote; the access you approve on Sentry’s consent screen is the boundary.

​

Scope a triage request

Name the Sentry organization, projects or workloads, time window, and relevant environments. For example: “Triage checkout errors in the storefront project in our Sentry organization over the last 24 hours, production only.” Roomote discovers accessible scope and asks for clarification when the target or window is missing or ambiguous instead of assuming project names or scanning other organizations. Include multiple organizations only when you want them scanned, and preserve any region-specific Sentry URL in your request. Triage scans stay read-only. Ask explicitly for follow-up work and identify the eligible repository or environment if you want findings turned into execution; otherwise recommendations stay in the report. Specify a report destination and whether clean scans should stay quiet. Access or scope blockers are reported rather than treated as a clean result. The built-in Triage Sentry Issues automation supplies its own schedule-derived scan window and configured project scope. Leaving its project slugs blank selects all projects available to the configured connection; it does not restore an implicit project list for ad hoc or custom triage requests. Roomote still asks which organization to use if that selection is ambiguous.

​

Recipes using this

• Triage customer issues