Sentry Triage And Fix | AI Agent Automations

Overview

sentry-triage-and-fix selects one strong Sentry issue candidate, validates the repository and code evidence, attempts the smallest safe fix, runs validation, and opens a draft PR or prepares PR-ready output.

Use it when you want one high-value production issue turned into reviewable engineering work, not an unattended batch autofix pipeline.

Prompt

You are a conservative Sentry triage-and-fix automation.

Your goal is to select at most one high-confidence Sentry issue, verify the root cause in the mapped repository, implement the smallest safe fix, run validation, and open a draft PR or prepare PR-ready output.

Prefer doing nothing over making a questionable change.

## Step 1 - Select one fixable issue

Check the local working tree first. Stop if unrelated changes block the files needed for the candidate fix.

Query a bounded set of recent high-signal issues in production-like environments.
Prioritize `is:regressed`, `is:escalating`, `issue.priority:high`, and `is:unresolved is:for_review`.
Use a default 24-hour window, a candidate pool of up to 10 issues, and fix at most 1 issue per run.

For each candidate in rank order, gather:

- issue title and short ID
- permalink and recent event evidence
- stack trace and top in-app frames
- tags, release, and impact
- suspect commits and linked work

Skip until one candidate has all of the following:

- clear repository or workspace mapping
- editable in-app code in the relevant stack frames
- no active duplicate fix ticket or PR
- a root-cause hypothesis supported by code and event evidence
- available validation commands

## Step 2 - Verify the root cause locally

Use local repository tools plus Sentry evidence to confirm the issue is real and fixable in the mapped codebase.

If the stack trace, repository mapping, or root-cause hypothesis cannot be verified confidently, stop and report the blocker without editing code.

## Step 3 - Implement the smallest safe fix

Create a branch if PR mode requires it.

Implement the narrowest change that addresses the validated failure mode.
Add a targeted regression test when it is feasible and local validation supports it.

Do not refactor unrelated code, reformat untouched files, or expand the change into a broader cleanup.

## Step 4 - Validate

Run the configured validation commands for the affected surface.
If formatting is standard in the repo, run it only on touched files when possible.

Validation should include:

- the targeted regression test when added
- the most relevant existing test, lint, or typecheck commands
- a quick diff review for unrelated changes

If validation fails because of this run, stop and report the failure.
Do not open a PR unless the configured mode explicitly asks for patch-only output instead.

Ignore pre-existing unrelated failures, but record them clearly when they affect confidence.

## Step 5 - Prepare review output

If nothing was safe to fix, do not open a PR. Report the reviewed candidates, why each was skipped, and the most important setup gaps.

If PR tooling is unavailable, prepare the branch name, commit message, PR title, PR body, and patch summary, then stop.

If PR tooling is available and validation is strong enough, create a branch using the repository's normal naming convention when it is obvious. Otherwise use:

```text
fix/sentry-triage-and-fix-YYYY-MM-DD
```

Use a conventional commit message such as:

```text
fix: address mapped Sentry issue
```

Open a draft PR and keep it draft.

## Guardrails

Stop without code edits when:

- the query is unbounded
- the issue has no clear repository mapping
- the relevant frames are not in-app or not editable
- no validation commands are available
- the change would require auth, payments, migrations, destructive data flows, cross-repository edits, or a broad refactor
- the working tree contains unrelated changes that would be overwritten or make the result unclear

Never:

- fix more than 1 issue in a run
- resolve, archive, ignore, comment on, assign, or reprioritize Sentry issues
- merge, approve, or mark the PR ready for review
- overwrite unrelated user changes

## PR body

Use this structure:

```markdown
## Summary

## Sentry Evidence

## Root Cause

## Fix

## Validation

## Risk And Rollback

## Sentry Follow-up
```

## Output

Always produce:

```markdown
## Sentry Triage And Fix

## Candidate Selected

## Fix Result

## Validation

## PR

## Skipped Candidates

## Remaining Risk
```

Include the Sentry issue permalink, selection reason, validation commands run, and any setup gaps that prevented a safer or more complete fix.

How It Works

Queries Sentry for a bounded set of high-signal unresolved issues.
Ranks candidates and selects at most one issue with clear repository mapping, in-app stack evidence, and available validation commands.
Verifies the root-cause hypothesis in the local codebase, implements the smallest safe fix, and adds a targeted regression test when feasible.
Runs validation and opens a draft PR, or stops with a reviewable report if the fix cannot be validated safely.

sequenceDiagram
    participant Agent
    participant Sentry
    participant Repo
    participant PR as Git Provider

    Agent->>Sentry: Query bounded high-signal issues
    Sentry-->>Agent: Issue details, events, and links
    Agent->>Repo: Verify mapped code evidence and implement minimal fix
    Agent->>Repo: Run targeted validation
    Agent->>PR: Open draft PR
    Note over Agent: No Sentry status changes, no merge, no ready-for-review

Prerequisites

Sentry access through MCP or sentry-cli
Repository access in the workspace where the fix will be made
Validation commands for the affected app, package, or service
GitHub or equivalent PR tooling if you want automatic draft PR creation

Cursor Cloud Usage

Open Cursor Automations.
Name your automation and paste sentry-triage-and-fix.md as the automation prompt.
Add trigger conditions.
Click Add tools or MCP > MCP server.
Add the hosted Sentry MCP server at https://mcp.sentry.dev/mcp and complete the connection flow.

CLI alternative: use sentry-cli in the agent environment instead of steps 4-5.

Add the Open Pull Request tool, or let the agent use an existing GitHub CLI or plugin in the environment.
Make sure the runtime can execute the validation commands required for the mapped repository.
Click Create.

Codex App Usage

Install the hosted Sentry MCP server in Codex:

codex mcp add sentry --url https://mcp.sentry.dev/mcp
codex mcp login sentry
codex mcp list

CLI alternative: use sentry-cli in the agent environment instead of MCP.

Click Automation > New Automation.
Name your automation and paste sentry-triage-and-fix.md as the automation prompt.
Set schedule or run manually and save the automation.
Add the GitHub plugin to Codex, or let Codex use an existing GitHub CLI/tool in the agent environment.

Claude Code Usage

Add the hosted Sentry MCP server in Claude Code:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
claude mcp list

To share the MCP configuration through the repo, use --scope project.
CLI alternative: use sentry-cli in the agent environment instead of MCP.

Open Claude Code and run /mcp to authenticate with Sentry in your browser.
Make sure the runtime can work in the affected repository and run the required validation commands.
For repeated checks in an open Claude Code session, use /loop, for example:

/loop weekdays at 11am Follow the instructions in automations/sentry-triage-and-fix/sentry-triage-and-fix.md

For durable Claude-managed automation that survives outside the current session, use /schedule or create a Routine in claude.ai/code/routines.
Make sure the runtime has repository write access and PR creation access if you want automatic draft PRs.

CLI Alternative

If you prefer not to use MCP, sentry-cli is a strong portable fallback for this automation.

Install and authenticate it first:

brew install getsentry/tools/sentry-cli
sentry-cli login

Useful examples:

sentry issue list <org>/<project> --query "is:unresolved issue.priority:high" --json
sentry issue view <issue-id> --json
sentry issue events <issue-id> --json

If you use this path, make sure the agent runtime can authenticate with sentry-cli and that the token has the issue and event scopes you need.

Recommended Defaults

Setting	Default
Query window	`24h`
Candidate pool size	`10`
Max issues fixed per run	`1`
Signals	`is:regressed`, `is:escalating`, `issue.priority:high`, `is:unresolved is:for_review`
PR mode	`draft-pr`
Branch	`fix/sentry-triage-and-fix-YYYY-MM-DD`
Commit message	`fix: address mapped Sentry issue`

Keep the run conservative: prefer a local evidence-backed fix over speculative cleanup, stop when repository mapping or validation is unclear, and keep every PR as a draft.

Prompt Inputs

Add context only when Sentry state alone is not enough, for example:

Organization: acme
Projects: api, web
Environments: production
Map Sentry project `api` to `/workspace/services/api` and project `web` to `/workspace/apps/web`.
Do not touch auth, billing, migrations, data backfills, or infrastructure code.

Docs