Root-cause with the evidence, not the guess

A Sentry issue is a claim about what broke. The job is to turn it into a claim about why it broke, backed by the event data, before anyone edits code.

1. Get the real issue, not the search hit

A pasted URL or short ID (PROJECT-123) goes straight to get_issue_details. A described error ("users can't check out") goes through search_issues first, but treat the results as candidates: match on the error type and the affected code path, not on title similarity. If two issues share a message but differ in stack trace, they are two bugs.

2. Read the stack trace like a diff

Fetch the newest event's stack trace. The top frame is where it crashed, not where it broke, walk down until you leave library code and hit the first frame owned by this repo. That frame and its local variables are the starting point. Cross-check the file against the working tree: production runs a release, and the line numbers may belong to code that has since changed. find_releases tells you which version the events come from.

3. Use the distribution before the theory

Before proposing a cause, check what the events have in common:

• Tags (get_issue_tag_values): one browser, one endpoint, one tenant, one release? A bug scoped to a dimension names its own trigger.
• Breadcrumbs: what the user did right before. A crash after a retry storm is a different bug than the same crash on first click.
• First seen / volume: an issue that started with a release points at that release's diff. One that grew slowly points at data or traffic.

Seer (analyze_issue_with_seer) is worth running for a second opinion, but verify its suggested cause against the frames yourself before repeating it.

4. Report cause, scope, and blast radius