← Back to Cookbook

Automate weekly performance triage with Claude Code + Sentry MCP

Set up a recurring Claude Code task that queries Sentry for your slowest endpoints every Monday, analyzes the root cause, and opens a GitHub PR with the fix. No custom bot infrastructure required.

Jump to recipe
Features
Performance ,  Tracing ,  Seer
Category Workflow
Share
Time
15-20 minutes
Difficulty
Beginner
Steps
7 steps

Before you start

Tools required
Accounts & access
  • Sentry account with tracing enabled and performance data flowing
  • Seer enabled for your organization
  • GitHub repo where performance PRs should be opened
  • Your Sentry organization and project slugs (needed for the scheduled task in Step 4)
Optional
  • GitHub integration configured in Sentry for Seer to access your source code

1
Connect the Sentry MCP server to Claude Code

The Sentry MCP server gives Claude Code read-only access to your issues, traces, spans, and Seer analysis through natural language. The fastest way to add it is with the Claude Code CLI. Run the command below, then type /mcp inside Claude Code to authenticate with your Sentry organization via OAuth. Once authenticated, Claude Code can query your Sentry data in any session, including scheduled tasks.

Sentry MCP server setup 
# Add via CLI (recommended)
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# Or add manually to ~/.claude.json
# {
#   "mcpServers": {
#     "sentry": {
#       "type": "http",
#       "url": "https://mcp.sentry.dev/mcp"
#     }
#   }
# }

2
Enable Seer and connect your GitHub repos

Seer is Sentry's AI debugging agent that uses Sentry data to create root cause analysis for issues, as well as fixes. You can query Sentry data using the MCP, but Seer is what guides you to what really caused the issue and how to fix it. Enable Seer in your org settings, then connect your GitHub repositories so Seer can examine your actual source code alongside trace data.

Seer documentation 
https://sentry.io/settings/seer
https://sentry.io/settings/integrations/github/

3
Verify the connection with a test query

Before setting up automation, test everything interactively. Open Claude Code and paste the prompt below. It tests the full chain: querying issues, pulling trace details, and running Seer analysis. Seer can take a few minutes to produce a root cause analysis, so give it time. If you see results returned, the connection is working end-to-end. If you get an authentication error, type /mcp to re-authenticate.

Sentry performance monitoring 
Find my top unresolved issues in Sentry, get the trace details for the worst one, and run Seer root cause analysis on it.

4
Create a weekly performance triage task

Claude Code scheduled tasks run a prompt on a cron schedule. Create a task that fires every Monday at 9 AM, queries Sentry for your worst performance issues, and opens GitHub PRs with fixes. Seer works best on error-type issues. For performance issues like N+1 queries and slow DB calls, Seer may or may not produce a fix, so the task prompt also has Claude Code analyze the code directly using the trace context. Between Seer and Claude Code's own analysis, most issues get actionable suggestions. The task runs in a fresh Claude Code session with full access to your MCP servers and shell.

  • Call search_issues with simple, single-topic queries (one issue type at a time, no OR/AND)
  • Call get_issue_details to pull the full trace context and trace ID for each issue
  • Call analyze_issue_with_seer to try Seer's root cause analysis (requires a real Sentry issue to work on)
  • Start with a cap of 2 PRs per run to avoid flooding your review queue
Claude Code scheduled tasks 
You are a performance triage bot. Run this workflow
from the repo at ~/code/your-repo.

Step 1 - Find performance issues:
  Call search_issues to find unresolved performance
  issues. Run separate queries for each type:
  - "unresolved N+1 query issues" (limit 3)
  - "unresolved slow db query issues" (limit 3)
  Do NOT combine queries with OR or AND.
  Use project slug: your-project
  Use org slug: your-org-slug

Step 2 - Get issue context and trace IDs:
  For the top 3 issues by event count, call
  get_issue_details on each. This returns the full
  trace, stack trace, and trace ID.

Step 3 - Analyze with Seer:
  Call analyze_issue_with_seer on each issue.
  Seer works best on error issues. For performance
  issues it may not return a fix. If Seer does not
  produce actionable suggestions, use the trace data
  and stack traces from Step 2 to analyze the code
  yourself and suggest a fix.

Step 4 - Open PRs:
  For each issue with a fixable root cause (from Seer
  or from your own analysis):
  a. Dedup check:
     gh pr list --repo owner/repo --search "perf:" --state open
  b. If no existing PR, create a uniquely-named branch:
     git checkout -b perf/fix-<issue-id>-<date> main
  c. Apply the fix, commit, push, and:
     gh pr create --title "perf: <root-cause-summary>"
       --body "Sentry issue: <url>\nTrace ID: <id>\n\n
       Root cause: <analysis>\nChanges: <summary>"
  d. Maximum 2 PRs per run.

Step 5 - Fallback:
  If neither Seer nor your own analysis can suggest a
  code fix, open a GitHub issue with the Sentry issue
  link, trace ID, and what you found.

Repository: owner/repo
Base branch: main

5
Verify the first scheduled run

Don't wait until Monday. Trigger the task manually for the first run. In Claude Code, open the scheduled tasks list and run your task on demand, or paste the task prompt into an interactive session to watch it execute step by step. Then check three things to confirm it worked:

  • The scheduled task list in Claude Code should show a lastRunAt timestamp
  • Your GitHub repo should have new PRs or issues created by the task
  • The Sentry traces linked in the PR body should match the span names and root cause that Seer reported
Sentry trace view

6
Tune thresholds and extend

Once the first run looks good, tune the task to match your team's signal-to-noise tolerance. Start with a high threshold (3000ms P95) and lower it as you build confidence in the PR quality. You can update the scheduled task prompt at any time without recreating it. Filter by specific Sentry projects or environments, increase the PR cap as reviewers build trust in the output, or create separate tasks for different services with different thresholds. GitHub already notifies your team when PRs are opened, so you get visibility without extra tooling.

Performance monitoring 
# Updated values in your task prompt:

# Lowered threshold - catch smaller regressions
P95 latency above 1000ms (was 2000ms)

# Increased cap - team trusts the output now
Maximum 3 PRs per run (was 2)

# Scoped to specific projects
Only search in: frontend-app, checkout-api

# Scoped to production only
Environment: production

7
Review and merge performance PRs

Each PR the task opens includes the Sentry trace link, Seer's root cause analysis, and a description of what changed and why. Review these the same way you would review any PR. Check the diff against the trace to verify the root cause makes sense, and run your test suite before merging. Over time, you'll develop a feel for which fixes are merge-ready and which need manual adjustment. If your team prefers to triage in Linear or another tool instead of PRs, modify the task prompt to create tickets there with the same trace links and analysis.

That's it.

Your performance triage is automated.

Every Monday, Claude Code queries Sentry for your slowest endpoints, runs Seer root cause analysis, and opens PRs with fixes. You don't have to check.

  • Configured the Sentry MCP server in Claude Code
  • Enabled Seer and connected your GitHub repos for accurate root cause analysis
  • Created a scheduled task that runs weekly performance triage automatically
  • Used `search_issues`, `get_issue_details`, and `analyze_issue_with_seer` to query and analyze performance data
  • Had GitHub PRs with performance fixes opened for you automatically

Pro tips

  • 💡 Run the task prompt interactively in Claude Code first. Paste it into a session and watch it call search_issues, get_issue_details, and analyze_issue_with_seer in sequence. This lets you verify the full workflow before the cron takes over.
  • 💡 The dedup check (gh pr list --search) prevents the same slow endpoint from generating a new PR every Monday. Always include this in your task prompt.
  • 💡 Combine this with Seer's automatic analysis. Seer handles reactive fixes when new issues fire. This scheduled task handles proactive performance sweeps. The two complement each other.
  • 💡 You can create multiple scheduled tasks for different thresholds or projects. Run a strict 500ms task for your checkout flow and a relaxed 3000ms task for internal tools.

Common pitfalls

  • ⚠️ Claude Code scheduled tasks are still a newer feature. Your machine must be on for the task to fire (it uses a local scheduler), each run starts a fresh session with no memory of previous runs, and tasks may stop running after a period of inactivity. If your weekly task stops firing, check the task list and recreate it.
  • ⚠️ Auth tokens can expire between runs. If scheduled runs start failing silently, open Claude Code interactively, run a Sentry MCP query to re-authenticate, and run gh auth status to verify GitHub access.
  • ⚠️ Include your repo path (e.g., ~/code/your-repo) and use unique branch names with the issue ID and date (e.g., perf/fix-PROJ-123-2026-03-10) in your task prompt. Without these, fresh sessions won't find your code or will collide with existing branches.
  • ⚠️ Treat auto-generated PRs as a starting point, not a guaranteed fix. Review the diff before merging and start with a cap of 1-2 PRs per run. If Seer references a file in a repo your GitHub integration can't access, the fix will be incomplete.
  • ⚠️ Seer is optimized for error-type issues. For performance issues like N+1 queries, Seer may not return a fix. The task prompt accounts for this by having Claude Code analyze the trace data directly as a fallback.
  • ⚠️ The Sentry search API does not support boolean operators (OR, AND) in queries. Always search for one issue type per query, or the search will fail with a 400 error.

Frequently asked questions

No. The Sentry MCP server provides read-only access. Claude Code can query issues, search spans, pull traces, and trigger Seer analysis, but it cannot create, update, or delete anything in your Sentry account.
Claude Code scheduled tasks use your existing Claude plan credits. A typical run analyzing 3-5 slow endpoints costs a few cents in token usage. There is no separate infrastructure cost: no CI minutes, no cloud functions, no servers to maintain.
The task won't fire while the machine is off. Claude Code uses a local scheduler, so the machine needs to be running for cron tasks to execute. If you need guaranteed uptime, consider running Claude Code on an always-on machine or cloud VM.
The Sentry MCP server at mcp.sentry.dev works with Sentry's cloud service (sentry.io). For self-hosted Sentry, you would need to use direct API calls via curl in the task prompt instead of the MCP tools.
No. This recipe uses Claude Code (which you already have), the Sentry MCP server (a remote URL, nothing to install), and the gh CLI (pre-installed on most developer machines). There is no package.json, no dependencies, and no build step.

What's next?

Add custom instrumentation for richer traces

The more detail in your traces, the better the fix suggestions. Add custom spans to database calls, external APIs, and business logic so the bot catches issues beyond the defaults.
Instrumentation docs →

Fix issues interactively with the Sentry MCP server

Use the same Sentry MCP server in Cursor or VS Code to pull issues, trigger Seer, and apply fixes on demand without waiting for the weekly sweep.
Try the IDE recipe →

Monitor your own MCP servers

If you build MCP servers, add Sentry monitoring to track tool performance, error rates, and client activity.
Monitor MCP servers →

Fix it, don't observe it.

Get started with the only application monitoring platform that empowers developers to fix application problems without compromising on velocity.

Try Sentry for Free Explore our Sandbox