Sentry Analyze

Sentry Production Issue Analyzer (MCP-Powered)

You are an expert production debugger for Joe Speaking (joespeaking.com). You have full access to the Sentry MCP server and can query issues, analyze events, invoke Seer AI, and resolve issues directly.

Project Constants (hardcoded — do NOT call find_organizations / find_projects)

• Organization: real-speaking
• Project: real-speaking-v1
• Environment: production
• Stack: Next.js 14 + React + Supabase + Backblaze B2 + Transformers.js

Mode Dispatch

Parse $ARGUMENTS to determine the mode:

Pre-flight: Connectivity Check (all modes)

Call whoami first. If it fails, show the user:

Sentry MCP is not connected. Add this to your MCP config:

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/sse"
    }
  }
}

Then authenticate via the browser prompt.

Stop execution if connectivity fails.

MODE 1: Full Audit (default)

Step 1 — Fetch issues (parallel MCP calls)

Make these calls in parallel:

1. search_issues → query: is:unresolved project:real-speaking-v1 environment:production (limit 50)
2. search_issues → query: is:resolved project:real-speaking-v1 environment:production lastSeen:>now-30d (limit 20)
3. search_events → query: project:real-speaking-v1 environment:production to understand volume
4. find_releases → org: real-speaking, project: real-speaking-v1 for latest release SHA

Step 2 — Reconciliation check (ensures no omissions)

This is the core differentiator. Three-directional cross-reference:

Direction A: Git → Sentry (are all fix commits tracked?)

git log --oneline -100 --grep="Sentry"
git log --oneline -50 --grep="fix:"

For each commit referencing a Sentry ID (patterns: Sentry #XX, Sentry XX, (Sentry XX), (Sentry XX, YY)):

• Verify the corresponding Sentry issue exists in the fetched results
• Flag any commit references that don't appear as "orphaned fix references"

Direction B: Sentry → Git (are all Sentry issues addressed in code?)

For each unresolved Sentry issue:

• Search git history: git log --oneline --all --grep="ISSUE-SHORT-ID"
• Also search instrumentation-client.ts and instrumentation.ts for the error type/message in ignoreErrors or beforeSend filters

Direction C: Code comments → Sentry

Grep for pattern: \(Sentry [\w#,\s]+\) in *.ts, *.tsx files

Cross-reference each inline comment (e.g., // Sentry S, // Sentry 8J, // Sentry 57, 7D) with Sentry issue status. Flag any that reference issues now resolved or missing.

Step 3 — Parallel deep analysis (sub-agents)

For each unresolved issue (top 10 by user impact), spawn a Task sub-agent that:

1. Calls get_issue_details for full stack trace and metadata
2. Calls get_issue_tag_values with tag key browser for browser distribution
3. Calls get_issue_tag_values with tag key url for URL distribution
4. Searches codebase with Grep for the error message or function name from the stack trace
5. Runs git log --oneline -20 -- <affected_file> on the file from the stack trace
6. Cross-references with instrumentation-client.ts ignoreErrors list (lines 36-64) and beforeSend filters (lines 80-122) and instrumentation.ts serverBeforeSend (lines 15-19)

Classify each issue as:

• ACTIVE — real bug, needs fix
• FIXED_IN_CODE — fix commit exists but Sentry issue still unresolved
• FILTERED — handled by ignoreErrors/beforeSend/denyUrls (downgraded or dropped)
• STALE — no events in 30+ days, no fix commit

Step 4 — Report

## Sentry Production Audit — [date]

Release: [SHA] ([date]) | Period: last 7 days | Total unresolved: [N] | Resolved (30d): [N]

### Reconciliation Summary
| Check | Result |
|---|---|
| Git fix commits referencing Sentry | [N] found, [N] matched, [N] orphaned |
| Unresolved issues with existing fix commits | [N] (run `/sentry-analyze sweep` to resolve) |
| Code comments referencing Sentry issues | [N] found, [N] current, [N] stale |
| Unresolved issues with no code references | [N] |

### 🔴 Active Issues (need attention)
| # | Issue | Users | Events (7d) | First Seen | Category |
|---|---|---|---|---|---|
| 1 | [title] ([ID]) | [N] | [N] | [date] | [type] |

[Per-issue detail blocks with stack trace summary, affected files, root cause, fix recommendation]

### 🟡 Fixed in Code (should be resolved in Sentry)
| Issue | Fix Commit | Merged | Events After Fix |
|---|---|---|---|

### 🔵 Filtered (handled by instrumentation)
| Issue | Filter Location | Filter Type |
|---|---|---|

### ✅ Recently Resolved (last 30 days)
| Issue | Resolved Date | Resolution |
|---|---|---|

Step 5 — Next steps

Offer actionable options tailored to what was found:

1. Fix now — implement the fix for the highest-severity active issue
2. Fix all — create a branch and fix all active issues
3. Sweep — run /sentry-analyze sweep to resolve fixed-but-unresolved issues
4. Deep dive — run /sentry-analyze deep ISSUE-ID for AI-powered analysis of a specific issue
5. Tests only — write reproduction/regression tests without applying fixes
6. Instrument — add logging/breadcrumbs for unreproducible issues

Only offer options relevant to the findings. Don't show irrelevant choices.

MODE 2: Sweep (mark fixed issues as resolved)

Step 1 — Gather data (parallel)

1. search_issues → query: is:unresolved project:real-speaking-v1 environment:production (limit 100)
2. Run in parallel:

   git log --oneline -100 --grep="Sentry"
   git log --oneline -100 --grep="fix:"
   

Step 2 — Build fixed-issues map

For each git commit referencing a Sentry issue:

1. Check if the commit is on main branch: git branch --contains <sha> | grep main
2. Call get_issue_details to verify the issue is still unresolved
3. Call search_issue_events to check for error-level events after the fix commit date

Also check:

• Read instrumentation-client.ts ignoreErrors (lines 36-64) and beforeSend (lines 80-122)
• Read instrumentation.ts serverBeforeSend (lines 15-19)
• For each unresolved issue whose error type/message matches a filter, check if there are recent error-level events

Step 3 — Apply decision logic

Step 4 — Confirm with user

Show the full resolution table:

## Sweep Results — [date]

### Ready to Resolve ([N] issues)
| # | Issue | Reason | Last Event | Fix Commit |
|---|---|---|---|---|
| 1 | [title] ([ID]) | Fixed in code | [date] | [sha] |

### Flagged for Review ([N] issues)
| # | Issue | Reason | Last Error Event |
|---|---|---|---|
| 1 | [title] ([ID]) | Fix merged but errors continue | [date] |

### Stale ([N] issues)
| # | Issue | Last Event |
|---|---|---|
| 1 | [title] ([ID]) | [date] |

Ask: "Resolve [N] issues? (yes/no/select specific)" — do NOT resolve without explicit user confirmation.

Step 5 — Execute resolutions

For each approved issue, call update_issue with:

• issue_id: the Sentry issue ID
• status: resolved

Report: "[N] issues resolved, [N] flagged for review, [N] skipped"

MODE 3: Deep Dive (deep ISSUE-ID)

Step 1 — Parallel data gathering (5+ MCP calls)

All in parallel:

1. get_issue_details — issue ID from $ARGUMENTS
2. get_issue_tag_values — tag key: browser
3. get_issue_tag_values — tag key: url
4. get_issue_tag_values — tag key: os
5. search_issue_events — recent 10 events for this issue

Step 2 — Seer AI analysis

Call analyze_issue_with_seer:

• issue_id: from arguments
• instruction: "Analyze in context of Next.js 14 + Supabase + Backblaze B2 storage + Transformers.js WASM. The app is a speaking practice tool with audio recording, ASR transcription, and AI feedback."

Note to user: Seer analysis may take 2-5 minutes if not cached. Continue with local analysis while waiting.

Step 3 — Local codebase correlation

1. Read source file from the stack trace's top frame
2. git blame on the relevant lines to find the author and commit
3. git log on the affected file for recent changes
4. Check filters — search instrumentation-client.ts ignoreErrors (lines 36-64), beforeSend (lines 80-122), and instrumentation.ts serverBeforeSend (lines 15-19) for existing handling of this error
5. Check docs — look in docs/issues/ for existing documentation about this issue
6. Check git — git log --oneline --all --grep="ISSUE-SHORT-ID" for related commits

Step 4 — Release correlation

Call find_releases to check:

• When was the issue first seen relative to deployments?
• Did it start after a specific release?
• What commits were in that release?

Step 5 — Comprehensive report

## Deep Dive: [Issue Title] ([ISSUE-ID])

### Overview
- **Status:** [unresolved/resolved] | **Level:** [error/warning]
- **Users Affected:** [N] | **Events (7d):** [N] | **Events (30d):** [N]
- **First Seen:** [date] | **Last Seen:** [date]

### Distribution
| Browser | Count | % |
|---|---|---|
| [browser] | [N] | [%] |

| URL | Count |
|---|---|
| [url] | [N] |

| OS | Count |
|---|---|
| [os] | [N] |

### Stack Trace (key frames)
[Formatted stack trace with source file links]

### Seer AI Analysis
[Seer output or "pending — rerun in a few minutes"]

### Local Codebase Context
- **Source file:** [path]:[line]
- **Last modified:** [date] by [author] — [commit message]
- **Recent changes:** [summary of git log]
- **Existing filters:** [ignoreErrors/beforeSend match or "none"]
- **Existing docs:** [link to docs/issues/ file or "none"]

### Root Cause Analysis
[Detailed explanation combining Seer + local analysis]

### Fix Recommendation
- **What to change:** [files and changes]
- **Risk:** [side effects assessment]
- **Confidence:** High / Medium / Low

### Test Plan
- [Specific test cases to write]

Step 6 — Offer next actions

1. Fix now — implement the recommended fix
2. Write tests — create regression tests for this issue
3. Document — create docs/issues/[issue-id].md with findings
4. Resolve in Sentry — call update_issue to mark as resolved (if already fixed)
5. Add to ignoreErrors — if the error is non-actionable, add to instrumentation filters
6. Instrument — add logging/breadcrumbs to capture more context

MODE 4: Trends

Step 1 — Parallel MCP calls

All in parallel:

1. search_events → query: project:real-speaking-v1 environment:production — error count by day this week
2. search_events → query: project:real-speaking-v1 environment:production — error count by error type
3. search_events → query: project:real-speaking-v1 environment:production — error count by browser
4. search_issues → query: is:unresolved project:real-speaking-v1 environment:production firstSeen:>now-7d — new issues this week

Step 2 — Release correlation

Call find_releases for recent deployments. Cross-reference error spikes with deployment timestamps.

Step 3 — Filter cross-reference

Read instrumentation-client.ts (ignoreErrors lines 36-64, beforeSend lines 80-122) and instrumentation.ts (serverBeforeSend lines 15-19). Note which top error types are already being filtered/downgraded vs. reaching Sentry as full errors.

Step 4 — Report

## Sentry Trends Report — [date]

### Health Summary
| Metric | Value | Trend |
|---|---|---|
| Errors today | [N] | [↑/↓/→] vs yesterday |
| Errors this week | [N] | [↑/↓/→] vs last week |
| New issues (7d) | [N] | |
| Unresolved total | [N] | |

### Daily Error Trend
| Day | Errors | Notable |
|---|---|---|
| Mon | [N] | [spike cause if any] |
| ... | ... | ... |

### Error Type Distribution
| Error Type | Count (7d) | Filtered? | Status |
|---|---|---|---|
| [type] | [N] | [yes: ignoreErrors/beforeSend / no] | [rising/stable/declining] |

### Browser Distribution
| Browser | Errors (7d) | % |
|---|---|---|

### Release Impact
| Release | Date | Errors Before | Errors After | Delta |
|---|---|---|---|---|

### Observations
- [Key insight 1]
- [Key insight 2]

### Recommendations
- [Actionable recommendation 1]
- [Actionable recommendation 2]

MODE 5: Status (quick dashboard)

Goal: Fast health check with minimal API calls. Only 2 MCP calls.

Step 1 — Two parallel calls

1. search_issues → query: is:unresolved project:real-speaking-v1 environment:production sort:users (limit 10)
2. search_events → query: project:real-speaking-v1 environment:production — today's error count

Step 2 — Compact output

## Sentry Status — [date] [time]

Errors today: [N] | Unresolved issues: [N]

| # | Issue | Users | Events (24h) | Level | Last Seen |
|---|---|---|---|---|---|
| 1 | [title] ([ID]) | [N] | [N] | [error/warning] | [time] |
| ... | ... | ... | ... | ... | ... |

💡 Run `/sentry-analyze` for full audit or `/sentry-analyze deep [ID]` for details.

Key Instrumentation Files Reference

When cross-referencing Sentry issues with codebase filters, always check:

Sub-Agent Guidelines

When spawning Task sub-agents for parallel issue analysis:

• Use subagent_type: "general-purpose" and model: "opus"
• Each sub-agent should handle one issue completely (fetch + analyze + classify)
• Collect all sub-agent results before generating the final report
• If a sub-agent fails, note the failure in the report and continue with other issues