Auto-fix regressed Sentry issues with Cursor Automations
When a resolved Sentry issue resurfaces, a Cursor agent investigates the regression vector, reads the relevant code, and opens a PR — no manual triage needed.
Before you start
SDKs & packages
- Sentry SDK installed and reporting events in your app
Accounts & access
- Sentry account with a project set up
- Cursor Pro or Business subscription (required for Automations)
- GitHub repository with your app's source code
Knowledge
- Basic familiarity with your app's codebase and repo structure
- Understanding of how Sentry issues are resolved and re-opened
1 Connect Sentry to your code repository
For the agent to trace regression vectors — identifying which commit reintroduced a bug — Sentry needs to know about your Git history. Connecting your repository lets Sentry annotate issues with the release they regressed in and link to the original resolving commit. Once connected, Sentry will start tagging regressed issues with a Regressed in release marker and surfacing the commit that originally closed the issue.
- Go to Integrations in your Sentry org settings
- Search for GitHub (or your provider) and click Install
- Authorize Sentry and select the repositories to link
- In your Sentry project settings, navigate to Code Mappings and map your source root to the repo path
2 Add the Sentry MCP to your automation
The Sentry MCP server gives your Cursor agent direct access to your Sentry issues, activity history, and stack traces. You add and authenticate it from within the automation's Tools section on cursor.com/automations — it isn't configured in the Cursor desktop app.
- Go to cursor.com/automations and click New automation (you'll finish configuring it in Step 4)
- In the Tools section, click + Add Tool or MCP
- Expand MCP Server and click + New Connection
- In the Browse MCPs dialog, search for
Sentryand select the Sentry plugin to add it - Back in Tools, click Authenticate on the Sentry row to launch the Sentry OAuth consent screen
- On the *Cursor is requesting access to Sentry* screen, enable at minimum Inspect Issues & Events (to read issue details and stack traces) and Triage Issues (so the agent can comment on the Sentry issue), then click Approve
3 Write the regression investigation instructions
Agent instructions are the prompt your Cursor Automation runs each time a regression is detected. The template below tells the agent to fetch full context from Sentry, identify the regression vector using git history, diagnose the root cause, apply a minimal fix if the scope is clear, and report results via PR or issue comment. Copy the template as-is and paste it into the Instructions field when creating the automation in the next step.
You are a regression investigator. You run when a Sentry issue transitions to "unresolved" — meaning it was previously resolved but has resurfaced, or was manually reopened.
## Step 1: Gather context from Sentry
Use @Sentry MCP to fetch the triggered issue. Extract:
- Issue title, type, and status
- Full stack trace from the latest event
- Breadcrumbs and request context
- The release where the issue regressed (check for "Regressed in release" marker)
- Activity history — find when and how it was previously resolved (commit, PR, manual, auto-resolve)
- Tags: environment, release, transaction, browser/runtime
## Step 2: Identify the regression vector
**If there's a resolving commit/PR in the activity history:**
- Find the original fix commit or PR on GitHub
- Identify which files were changed in that fix
- Run `git log <resolving-commit>..HEAD -- <those files>` to find what changed since
- Read the original fix diff and the subsequent diffs to understand what undid it
- Common causes: partial reverts, merge conflicts that dropped lines, refactors that moved code without carrying the fix, dependency updates
**If there's no resolving commit (auto-resolved, manually resolved):**
- Focus on the stack trace to identify the relevant source files
- Check recent git history for those files
- Read the current code at the crash site
## Step 3: Diagnose root cause
Read the relevant source files. Cross-reference stack trace frames with actual code. Identify:
- What specifically is failing
- Whether a recent commit introduced or reintroduced the bug
- The simplest possible fix
## Step 4: Assess fixability
Fix it if:
- Root cause is clear from the stack trace + code
- Fix is scoped to 1-3 files
- It's a code-level bug (null check, wrong condition, missing await, type error, bad API usage)
Do NOT fix it if:
- The issue is in a third-party dependency or infrastructure
- The fix requires architectural changes or touching >5 files
- You can't confidently determine root cause
- It's environment-specific (secrets, API keys, rate limits)
If not fixable, skip to Step 6.
## Step 5: Apply the fix
- Branch: `fix/<sentry-issue-short-id>-<short-description>`
- Apply the minimal fix only. Do not refactor surrounding code.
- Match existing code style and conventions.
- Run the project's type checker and linter to confirm no regressions.
## Step 6: Report results
**If fixed — open a PR:**
- PR title: `fix: <what broke>` (under 70 chars)
- PR body: include the Sentry issue link, root cause, regression vector (commit/PR if identified), and what this PR changes
**If not fixable:**
- Comment on the Sentry issue with: root cause hypothesis, relevant commits, and what a human should investigate
## Rules
- Never refactor, add features, or improve code beyond the fix
- A clear diagnosis without a PR is better than a speculative PR
- Check @Memories before starting to avoid duplicating work on the same issue
- Save to @Memories: the issue ID, root cause, and PR link (or why it couldn't be fixed) 4 Configure the trigger and launch the automation
Cursor Automations are background agents that fire automatically based on a trigger. Back in the automation you started in Step 2 on cursor.com/automations, wire up the Sentry trigger, paste your instructions, and launch it. Sentry's available triggers are Issue created, Issue updated, and Any issue event — regressions come through as status updates, so you'll use Issue updated and let the agent's instructions filter for the regression case.
- Name the automation (e.g. "Regressed Issue to PR")
- Under Triggers, add Issue updated → select your Sentry project and environment
- Confirm Tools has Sentry (from Step 2), and add Open Pull Request and Memories
- Paste your instructions from Step 3 into the Instructions field
- Keep Environment set to *Cursor Cloud* so the agent runs without your machine being on
- Click Create to launch the automation
5 Test the automation end-to-end
Before relying on the automation in production, verify the full pipeline: regression detected in Sentry → Cursor agent fires → investigation runs → output is useful.
- Find a recently-resolved Sentry issue and manually reopen it, or wait for a real regression to occur
- In your newly created automation, switch to the Run History tab at the top to watch the agent spin up
- Check the agent trace to confirm it fetched the right issue from Sentry, ran git history analysis, and produced a conclusion
- If the agent opens a PR, review the diff and PR body to assess quality
- If the agent leaves a comment on the Sentry issue, confirm the diagnosis is actionable
6 Review and merge the agent's PR
When the agent opens a PR, treat it like any other code review. The bar for merging an auto-generated fix should be the same as a human-authored one — diff review, test pass, and confidence in the root cause. For regressions the agent couldn't fix, the Sentry issue comment gives your team a documented starting point: what broke, when, and what a human should look at.
- Read the PR body: it should name the Sentry issue, the regression vector (if found), and what changed
- Review the diff: confirm it's minimal and matches the described fix
- Run your test suite before merging
- If the fix is wrong or too broad, close the PR and add a clarifying rule to the agent instructions
- For unresolvable issues, use the Sentry comment as the starting point for manual triage
That's it.
Regressions get fixed, not just noticed.
When a resolved issue resurfaces in Sentry, a Cursor agent wakes up, traces which commit reintroduced the bug, and opens a PR — so your team reviews fixes, not alerts.
- Connected Sentry to your Git repository for commit-level regression tracking
- Configured the Sentry MCP server in Cursor for in-agent issue access
- Created a Cursor Automation that responds to Sentry issue regressions
- Wrote agent instructions that trace regression vectors and open fix PRs
Pro tips
- 💡 Add a line in your instructions to check
@Memoriesbefore starting. If the agent has already investigated the same issue ID, it should skip the run rather than duplicating work. - 💡 Scope your Sentry project trigger to a specific environment (e.g.
productiononly). Running on every environment will fire the agent on dev or staging regressions that aren't worth automated investigation. - 💡 Include a brief map of your repo's key directories in the agent instructions. This lets the agent find relevant files faster without scanning the entire codebase on every run.
- 💡 Pair this automation with Sentry's commit-based auto-resolve to automatically mark issues resolved when a fix is merged. This keeps the regression trigger clean and ensures the automation only fires on genuine regressions.
Common pitfalls
- ⚠️ Skipping the Git repository connection in Sentry. Without it, the agent has no resolving commit to trace back from, making regression vector analysis much harder and less reliable.
- ⚠️ Not scoping the trigger to a specific environment. If the automation fires on every project and environment, you'll burn Cursor agent runs on regressions that don't warrant investigation.
- ⚠️ Writing instructions that are too permissive about what the agent can change. Always add explicit rules about how many files it can touch and what constitutes a fixable vs. unfixable regression.
- ⚠️ Not testing the automation end-to-end before relying on it in production. The Sentry trigger, MCP connection, git access, and PR creation all need to work together — test each piece before shipping.
Frequently asked questions
What's next?
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.