/find-in-sentry

name: find-in-sentry
description: Answer "what's breaking" questions from Sentry — find the right org and project, search issues and events with the vocabulary Sentry uses, and report what is actually firing rather than the first hit. Use when the user asks what errors are happening, whether something is stable, what changed since a release, or for any health summary of a service.
argument-hint: the service, error, release, or question to look up
allowed-tools: mcp__sentry__whoami, mcp__sentry__find_organizations, mcp__sentry__find_projects, mcp__sentry__find_releases, mcp__sentry__search_issues, mcp__sentry__search_events, mcp__sentry__get_issue_details

Find what is actually firing

Sentry answers precise questions precisely and vague questions misleadingly. The work is scoping the question before searching, and ranking what comes back by impact instead of by relevance.

1. Scope to the right project first

Run `find_organizations` and `find_projects` before searching if you are not certain where the code reports to. A monorepo often maps to several Sentry projects (api, web, desktop), and a search in the wrong one returns a confident, empty answer. Say which project you searched.

2. Search the way Sentry indexes, not the way people ask

"Is checkout broken?" becomes queries on what Sentry actually stores: the error type, the transaction or URL, the release. Prefer `search_issues` for "what problems exist" and `search_events` for "how often / for whom / since when". Run two or three narrow queries over one broad one, and time-bound them — `is:unresolved` over the last 24h answers a different question than all-time.

3. Rank by impact, not by recency of the search result

The issues worth reporting are the ones with high event counts, many affected users, or a first-seen that matches a recent release. A brand-new issue with three events can matter more than a year-old one with thousands — say why the ones you picked matter. When a number is load-bearing (error rate, affected users), take it from `search_events` rather than eyeballing the issue list.

4. Answer with links and the time window

Every issue you cite gets its Sentry link and the window you looked at. "No matching issues in the last 7 days in `api`" is a complete, useful answer — silence about scope is how "it's fine" turns out to mean "I searched the wrong project".

Anti-patterns

• **Reporting the first page as the truth.** Sort order is not severity.
• **Mixing environments.** Production noise and staging noise answer different

questions; filter to the environment the user cares about.

• **Counting issues to measure health.** Ten one-off issues can be healthier

than one issue hitting every user; lead with events and users affected.

• **Answering "is it stable" without a baseline.** Compare against the prior

window or the prior release, not against zero.