How to trigger a Cursor agent directly from a Sentry error

Yes. Sentry ships a real, documented integration that sends a bug from Seer's root cause analysis straight to a Cursor Cloud Agent, which then writes and opens the fix as a pull request. It isn't a webhook you have to build or a Zapier chain someone stitched together. Sentry and Cursor both maintain this path, and it's been live since November 2025.

The mechanics are simple enough to set up in an afternoon. The part worth being honest about upfront is what the handoff doesn't carry. Stack traces and root cause come through fine. Who's affected, and how much the affected account is worth, doesn't. That gap is what determines whether this pipeline is enough on its own or needs something layered on top.

What actually connects Sentry to Cursor

The feature lives inside Seer, Sentry's paid AI debugging add-on, and it isn't available on a plan without Seer enabled. Billing is per contributor, not per repo. Anyone who opens two or more PRs or MRs in a month in a Seer-enabled repo gets billed as an active contributor that month, per Sentry's Seer docs. One person who hits that threshold across several repos counts; two different people who each open one PR in the same repo don't. Setup is three steps:

1. In Sentry, go to Settings > Integrations > Cursor Agent and install it (requires Owner, Manager, or Admin access).
2. Generate a Cursor API key from Cursor's account settings, under Integrations > User API Keys, and paste it into the Sentry integration form.
3. Optionally, open your project's Seer Automation settings and set Cursor Cloud Agent as the default coding agent for issues that reach the "generate a fix" stage.

With that done, there are two ways a Cursor agent actually gets triggered. Manually, by opening any issue, finding the Seer Root Cause Analysis card, and clicking the dropdown next to "Find Solution" to send it. Or automatically, once Cursor is set as the default agent in Seer Automation, where qualifying issues get handed off without anyone clicking anything, as they cross whatever threshold the automation rule defines.

Either way, the handoff itself is narrow. Sentry sends Seer's stack trace and root cause analysis to the Cursor Cloud Agent, the agent opens against your repo, and a pull request comes back. Nothing about who hit the error, or what their account is worth, travels with it, because Sentry doesn't have that to send in the first place.

What the agent does with what it's given

Once triggered, the Cursor Cloud Agent works against your actual repo, not just the diff Seer suggests. It has the full codebase checked out, so per Cursor's own docs it can build the project, run the test suite, and interact with the changed software before opening a pull request. Sentry's own framing for the result is straightforward. You come back to a ready PR in your repo, not a snippet to paste in yourself.

That's a meaningfully different output than most "AI suggests a fix" features, which stop at a diff in a comment. A PR that already passed the test suite is something a human can review and merge in minutes, not something that needs its own round of manual verification first.

Where a fix ships and nobody outside engineering finds out

Kiran Deol is a staff engineer at Basalt Analytics, a usage-metering platform for API companies. A Sentry issue fires overnight. A null pointer in the billing-rollup job, 60-odd events, all against Torrance Data, an enterprise workspace that switched to hourly billing the week before. Seer's automation is set to hand off to Cursor for exactly this class of issue, and by the time Kiran checks Sentry at 9am, there's already a PR waiting. The rollup job now guards against the missing field, the existing tests pass, and a new one covers the case.

Kiran reviews it, merges it, and the fix ships before lunch. Nothing in the Sentry issue or the Cursor PR says which customer hit it or that the account is mid-migration to a new plan, so nobody outside engineering hears about it.

The gap surfaces two days later, in prep notes for Torrance Data's renewal call. Their usage dashboard looked wrong on Tuesday, and the account manager building the call notes has nothing on file about why. Kiran pulls up the merged PR, matches the timestamps, and adds a line to the deal record explaining what happened and when it shipped. The bug took under twelve hours to fix. The part that took two days was the fix reaching anyone who could tell the customer about it.

The three things this handoff can't tell you

Seer plus Cursor is a genuinely good pipeline for what it's built to do. It turns a reproducible error into a reviewed fix with as little manual work as possible. It runs out at one specific, predictable point, which is the moment someone other than the engineer who merged the PR needs to know the error happened.

• No account attached. Sentry's setUser() context gives you a user ID at best, not an account name, an ARR figure, or a renewal date. Seer and Cursor never see any of that, because Sentry doesn't have it to hand them.
• No cross-issue memory. If the same root cause resurfaces as a second, slightly different stack trace next month, the pipeline treats it as a new issue with no link back to who was already told about the first one.
• No downstream notification. The PR merging is the end of the automation. Telling support, sales, or the affected customer that the underlying bug is fixed is a separate, manual step every time.

Below a handful of customer-facing bugs a week, someone can carry that last step in their head. Past that, it's the same gap our guide on finding out which customers hit a Sentry error covers from the Sentry side, and the one our guide on reviewing what a Cursor background agent changed before it opens a PR covers from the Cursor side. Both tools do their piece well, and neither one is responsible for the piece in between.

What Modem adds to the same pipeline

This is the exact gap we built Modem to close. Modem watches the same Sentry issues Seer analyzes, and links each one to the company and person record it already builds from your support conversations, sales calls, and Slack threads. When an error fires against an enterprise workspace mid-renewal, that fact is attached to the issue before anyone has to go looking for it. When the fix lands, whether Cursor wrote it or a person did, Modem drafts the update to the account team and the affected customer, instead of leaving that for someone to remember two days later. The Modem Sentry integration reads issues, stack traces, and user feedback directly; it doesn't replace Seer's root cause analysis or Cursor's fix generation, it fills in who was waiting on the other end. We build Modem, so weigh that against the fact that below a certain volume, an engineer checking in with account management by hand costs nothing extra.

Start manual, automate once you trust it

If you already pay for Seer, connecting Cursor is the three steps above and costs nothing beyond what you're already paying for active contributors. Turn on manual triggering first, watch a few PRs come back, and only flip on full automation once you trust the fixes it's producing unattended. The context gap is real, but it's not a reason to skip the integration. It's a reason to have a second system, or a person, watching for who needs to hear about the fix once it ships.