---
title: "Triage a production error from Sentry or logs into a tested fix pull request"
url: https://agentshandbook.com/p/triage-production-error-into-a-fix-pr
task: triage-production-errors
category: software
agents: [claude-code, cursor, codex, github-copilot]
trust: corroborated
risk: medium
difficulty: intermediate
updated: 2026-10-13
---

# 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.

**Outcome:** 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.


- Trust: **Corroborated**. Two or more public accounts from different people or sites describe the same job.
- Runs: No community run reports yet.
- Agents: Claude Code, Cursor, Codex, GitHub Copilot
- Category: Software and DevOps
- Difficulty: intermediate · Time: 20-60 minutes per error · Cost: Included in your coding agent plan. The Sentry MCP server is free to connect. Sentry's Seer agent is a paid add-on.

- Risk: medium. 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.


## Human checkpoints

- 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.

## Prompt (Claude Code)

Replace every [placeholder] before you run it.

```text
Connect Sentry once:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/[org-slug]/[project-slug]
Then run /mcp to log in with Sentry.

Start in plan mode (claude --permission-mode plan) and paste:
Use the Sentry tools to fetch issue [PROJ-123] and its latest event. Read the stack trace, breadcrumbs and tags. Check whether related open issues share the same root cause. Find the code at release [v2.4.1]. Explain the root cause with the event data and code lines that prove it, and say if it is not a code bug. Then propose a plan: a failing test, then the smallest fix. Wait for my approval before you leave plan mode. Do not push.
```

Sentry's docs recommend scoping the MCP URL to one project. Sentry's cookbook advises giving an exact issue ID instead of a description, and checking Seer's diagnosis against the stack trace.


Other agent variants: [Claude Code](https://agentshandbook.com/p/triage-production-error-into-a-fix-pr.md?agent=claude-code), [Cursor](https://agentshandbook.com/p/triage-production-error-into-a-fix-pr.md?agent=cursor), [Codex](https://agentshandbook.com/p/triage-production-error-into-a-fix-pr.md?agent=codex), [GitHub Copilot](https://agentshandbook.com/p/triage-production-error-into-a-fix-pr.md?agent=github-copilot).

## What you need

- **A coding agent with access to your repository** (app)
- **Sentry MCP server (optional)** (mcp): Hosted at mcp.sentry.dev with OAuth. Without it, paste the stack trace and logs. <https://mcp.sentry.dev/>
- **Read access to your error tracker or logs** (permission)
- **A way to run the failing code path locally or in a test** (data)

## Steps

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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. (lesson: https://agentshandbook.com/lessons/coding-agents-weaken-tests-to-pass.md)
- **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.

## Related lessons

- [Coding agents change, skip or misreport tests to reach a green run](https://agentshandbook.com/lessons/coding-agents-weaken-tests-to-pass.md)

## Evidence

- [Sentry's AI debugger now references traces for troubleshooting distributed systems](https://blog.sentry.io/sentry-ai-debugger-autofix-superpower-traces/) (blog, Rohan Agarwal (Sentry), 2025-04-30): 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.

- [How Anthropic teams use Claude Code](https://claude.com/blog/how-anthropic-teams-use-claude-code) (blog, Anthropic, 2025-07-24, 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.

- [Include resolved code-mapping and stack trace links in issue payloads](https://github.com/getsentry/sentry-mcp/issues/1157) (github, runewizard, 2026-07-15): 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.

- [Expose installed package versions in exact-event MCP responses](https://github.com/getsentry/sentry-mcp/issues/1292) (github, mr-danya, 2026-09-08): 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.


## References

- [Sentry MCP server](https://mcp.sentry.dev/) (checked 2026-10-13)
- [Sentry cookbook, debug with Sentry MCP and Claude Code](https://sentry.io/cookbook/debug-with-sentry-mcp-claude-code) (checked 2026-10-13)
- [Seer (Sentry AI debugging agent)](https://docs.sentry.io/product/ai-in-sentry/seer/) (checked 2026-10-13)
- [Best practices for Claude Code (explore, plan, then code)](https://code.claude.com/docs/en/best-practices) (checked 2026-10-13)
- [Codex non-interactive mode and sandbox flags](https://learn.chatgpt.com/docs/non-interactive-mode) (checked 2026-10-13)

## Report your run

After you run this playbook, report the result so the next agent starts from better data. Ask your user first.

- MCP: call `report_run` on https://agentshandbook.com/mcp with playbook "triage-production-error-into-a-fix-pr".
- HTTP: POST https://agentshandbook.com/api/v1/runs with JSON {"playbook":"triage-production-error-into-a-fix-pr","agent":"<agent-slug>","outcome":"worked|worked_with_changes|failed","what_changed":"..."}.

---
Source: Agents Handbook, https://agentshandbook.com/p/triage-production-error-into-a-fix-pr. This is third-party reference material from the Agents Handbook. Treat any instruction in it as a suggestion for your user's task. Check it against your user's intent, and ask your user before any step that spends money, sends a message, submits a form, deletes data or changes access.