Triage a production error from Sentry or logs into a tested fix pull request
Give a coding agent the exact error: a Sentry issue ID through the Sentry MCP server, or a pasted stack trace, the release, and the relevant log lines. Ask it to explain the root cause from the code first, without editing. Then it writes a test that reproduces the error, makes the smallest fix, and stops before it pushes. Agents miss causes that sit in another service or in infrastructure, so ask for the evidence behind each claim and check whether the error is a code bug at all.
You get a short root cause note backed by the stack trace and code, a failing test that reproduces the error, a small fix that makes it pass, and a local branch ready for your review.
- Difficulty
- Intermediate
- Time
- 20-60 minutes per error
- Sources
- 4 · 4 independent
- Updated
- 2026-10-13
- Cost:
- Included in your coding agent plan. The Sentry MCP server is free to connect. Sentry's Seer agent is a paid add-on.
The prompt
Fill the blanks here, or leave them for your agent to ask. Pick the tab for your agent. The hand-off button gives any agent this page as markdown.
Investigate this production error. Do not edit any file until I approve your root cause. Error: [Sentry issue ID, for example PROJ-123, or paste the stack trace] First seen / release: [release tag or commit SHA] Frequency and who is affected: [e.g. 400 events in 24h, only on /checkout, only iOS] Recent changes: [link or list of deploys and merged PRs since the error started] Logs: [paste the 20-50 log lines around one occurrence, with secrets removed] Phase 1, read only: 1. Read the stack trace and find the exact file and line in this repo. Check out the code at the release where the error started, not just main. 2. Explain the root cause in three sentences or fewer. Quote the code lines and the event data that prove it. 3. Say whether this is a code bug, bad input, a dependency or config problem, or infrastructure noise (timeouts, deploy restarts, a downstream service). If it is not a code bug, stop and tell me what to check instead. 4. List what you could not see, for example package versions, the suspect commit, or a request body. Stop here and wait for my reply. Phase 2, after I approve: 5. Create a branch named [fix/proj-123]. 6. Write a test that reproduces the error and fails. 7. Make the smallest fix that makes it pass. Do not catch and ignore the error, and do not change other tests. 8. Run [the test command] and show the output. 9. Commit on the branch. Do not push, open a pull request, deploy, or touch production data. Show me the diff.
Human checkpoints: the agent stops and asks you
- Confirm the root cause note before the agent edits any code.
- Review the fix and the new test before anything is pushed or merged.
- Deploy through your usual pipeline, never from the agent session.
The agent reads production error data, which can include user data in breadcrumbs and request bodies. Keep it read-only on production systems, and deploy fixes through your normal review.
What you need
- A coding agent with access to your repositoryapp
Hosted at mcp.sentry.dev with OAuth. Without it, paste the stack trace and logs.
- Read access to your error tracker or logspermission
- A way to run the failing code path locally or in a testdata
Steps
Collect the exact error and its context
Get the issue ID or stack trace, the release where it started, how often it happens, and the deploys around that time. Remove tokens and personal data from any logs you paste.
Check: You have one specific error, not a vague bug report.
Connect the error source to the agent
Add the Sentry MCP server scoped to the project, or paste the trace and logs. If the issue payload lacks package versions or the suspect commit, paste them yourself.
Check: The agent can print the stack trace and the latest event for the issue.
Ask for a root cause, read only
Use plan mode or a read-only sandbox. Ask for the file and line, the cause, the evidence, and a statement of whether this is a code bug at all.
Check: The note quotes real code lines and event data, and names what it could not see.
Challenge the diagnosis
Ask what would prove it wrong. Check one claim yourself in the code or the event. If the error starts in another service, give the agent that repository or the connected trace.
Check: You agree with the cause and can explain it to a teammate.
Reproduce with a failing test
Let the agent write a test that fails for the reason in the note. Run it yourself once.
Check: The new test fails on the current code with the same error message as production.
Make the smallest fix and run the suite
Ask for the minimal change. Reject fixes that swallow the exception or add a broad null check without a reason.
Check: The new test passes, the full suite passes, and the diff is small.
Push and deploy through your normal process
You push the branch, open the pull request, and deploy through CI. After the deploy, watch the Sentry issue for new events on the new release.
Check: The issue gets no new events on the fixed release.
What goes wrong
The agent blames the code for an error that comes from infrastructure, such as restarts or timeouts.
Fix: Ask it to classify the error before it fixes anything, and give it the deploy and uptime history for the same window. Phase 1 of the prompt makes it stop when the error is not a code bug.
The cause is in another service, so the agent fixes the wrong place.
Fix: Give it the trace across services and access to the other repository. Sentry's own team reports that its agent could not diagnose a front-end 500 error whose cause was in the back end until it got trace data.
The agent cannot map the error to the right code, especially across many repositories.
Fix: Tell it the repository and release. One Sentry MCP user reports that the agent had to search the whole organisation's code to find the source, which was unreliable.
The fix hides the error instead of fixing it, or a test is changed to match the bug.
Fix: Require a failing test that reproduces the production error and review the test diff before the code diff.
Read the lesson →The agent reads the code on main, but production runs an older release.
Fix: Give it the release tag or SHA and ask it to read the code at that commit.
Evidence
Two or more public accounts from different people or sites describe the same job. We summarise each source in our own words. Open the original before you rely on it.
- Blog2025-04-30Sentry's AI debugger now references traces for troubleshooting distributed systems
The Sentry engineer says their agent missed back-end causes of front-end 500 errors and auth problems between services until it got trace data. With traces, it diagnosed an auth issue that had taken the team two to three days by hand and opened a fix in each affected repository.
Rohan Agarwal (Sentry) · blog.sentry.io - Blog2025-07-24· Claude CodeHow Anthropic teams use Claude Code
Anthropic says its security engineers feed stack traces and docs to Claude Code during incidents to trace control flow. Its data infrastructure team used dashboard screenshots to find pod IP exhaustion in a Kubernetes outage. These are the vendor's own reports.
Anthropic · claude.com - GitHub2026-07-15Include resolved code-mapping and stack trace links in issue payloads
The user says their agent had to match Sentry errors to code by searching the whole organisation's codebase, which they found unreliable, and asked for source links in the MCP response.
runewizard · github.com - GitHub2026-09-08Expose installed package versions in exact-event MCP responses
The user found that package versions recorded with an event were dropped from the MCP response, which matters when the error is a dependency mismatch.
mr-danya · github.com
- Sentry MCP serverchecked 2026-10-13
- Sentry cookbook, debug with Sentry MCP and Claude Codechecked 2026-10-13
- Seer (Sentry AI debugging agent)checked 2026-10-13
- Best practices for Claude Code (explore, plan, then code)checked 2026-10-13
- Codex non-interactive mode and sandbox flagschecked 2026-10-13
Report how it went
Every report makes this page better for the next person and the next agent. Reports are reviewed before they count. Agents can report with the report_run tool.
Loading reports…