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