mcpservers

Recipe

Turn a Sentry error into a triaged GitHub issue with Claude

An alert fires. In one prompt Claude reads the stack trace, pulls the code, judges severity, and writes the GitHub issue you'd have written by hand.

20 minutes (10 to set up the first time, 5 per alert after) intermediate 2 connectors for Developers and on-call engineers who get a Sentry alert and have to turn it into an actionable ticket

What you'll need

Sentry Reads the error, its stack trace, how often it's firing, and which release introduced it.
Required
GitHub Reads the code the trace points at and creates the triaged issue.
Required

Do this, in order

  1. 1

    Pull the error and its trace

    Read Sentry issue [SENTRY-ID or paste the Sentry URL]. Give me: the exception, the top of the stack trace, how many times it's fired in 24h, how many users hit it, and which release first saw it.

    You'll get: A compact incident summary. The frequency and user count are what tell you whether this is a page-someone or a file-it problem.

  2. 2

    Get the actual code, not just the message

    Using GitHub MCP, open the file and function at the top of that stack trace in your-org/your-repo. Show me the relevant lines and explain what input would make this throw.

    You'll get: The real source around the failing line, plus a concrete description of the failure condition — not a restatement of the error message.

  3. 3

    Make a severity call

    Given frequency, user impact, and what the code does: rate this P1 / P2 / P3 and justify it in one sentence. P1 = active user-facing breakage, P3 = noisy but harmless.

    You'll get: A single severity with a one-line reason. You can override it, but now the override is a decision, not a guess.

  4. 4

    Write the triaged issue

    Create a GitHub issue in your-org/your-repo titled with the exception and location. Body: summary, suspected cause, reproduction steps, the file:line, severity from step 3, and a link back to the Sentry issue. Label it bug and the severity. Show it to me before creating.

    You'll get: A drafted issue you read and approve, then Claude creates it on GitHub with labels and the Sentry backlink. Nothing is filed without your approval.

You're done when

A raw Sentry alert becomes a triaged, reproducible GitHub issue — with the offending code identified, a severity call, and a Sentry backlink — in about 5 minutes instead of 20. Whoever picks it up starts fixing instead of investigating.

Why this workflow exists

The fix for a production error is usually small. The expensive part is everything before the fix: open the alert, read the trace, find which line in which file, pull that code, figure out what input breaks it, decide how urgent it is, and write a ticket clear enough that someone can act. That investigation happens at the worst time — mid-incident — and it’s almost entirely mechanical.

This workflow hands the mechanical 20 minutes to Claude. It reads the error where it lives, pulls the real code the trace points at, makes a severity call against thresholds you set, and drafts the issue. You stay the decision-maker on severity and on whether the issue is filed. You stop being the one assembling context under pressure.

The first run takes ~20 minutes for setup. After that, alert to triaged issue is about 5 minutes.

Install in 10 minutes

You need both Sentry MCP and GitHub MCP — the whole value is connecting the error to the code.

1. Install Sentry MCP

claude mcp add --transport sse sentry https://mcp.sentry.dev/sse

Auth is OAuth in the browser on first use. The maintained endpoint is on the Sentry MCP page. Verify with /mcp — sentry should be connected.

2. Install GitHub MCP

claude mcp add github -- npx -y @modelcontextprotocol/server-github

Set GITHUB_PERSONAL_ACCESS_TOKEN with repo read and issue write scope. Scopes are on the GitHub MCP page.

The first run

Don’t wait for a real incident — practice on an existing noisy P3 in Sentry so you’re not learning the workflow while something is on fire. Run prompt 1 and look at frequency and user count first; that’s the part humans skip and then misjudge severity.

Run prompt 2 and confirm Claude opened the actual code, not just paraphrased the error. Make the severity call in prompt 3 against real thresholds. Draft the issue in prompt 4, read it, and approve before it’s filed — issues are created only on your say-so.

What success looks like

An alert fired. Five minutes later there’s a GitHub issue with the exception in the title, the failing file:line in the body, a reproduction derived from the trace, a severity with a stated reason, and a link back to Sentry. The next person opens it and writes a fix — they never had to do the investigation, because it was already done.

Going further

If something breaks

Claude explains the error message but never opens the code
Fix: It needs the repo path. Be explicit in step 2: 'open the actual file in your-org/your-repo at the path in the trace' — without the repo named, GitHub MCP has nothing to read.
Severity is always P1
Fix: Give it the thresholds, not adjectives: 'P1 only if >50 users in 24h or it blocks signup/checkout; otherwise P2; P3 if zero user-facing effect.' Numbers make the call consistent.
The Sentry MCP connection drops mid-investigation
Fix: Sentry MCP is a remote SSE server; long idle gaps drop it. Re-run the connect step (see the Sentry MCP page) and do the investigation in one pass rather than across a long conversation.
Reproduction steps are generic ('trigger the error')
Fix: Tell it to derive steps from the trace and code, not the message: 'what specific request, input, or state from the stack frames produces this?' If it can't say, the issue should be labeled needs-repro, and that's still useful.

Related

Sentry GitHub github pr auto review