What the agent does
The run reads Sentry through Sentry's remote MCP server, https://mcp.sentry.dev/mcp, the Sentry entry in the Rush connector catalog, which can query issues, errors, events and traces. Connect it once with POST /me/connections {"type": "mcp", "name": "sentry", "url": "https://mcp.sentry.dev/mcp", "auth": {"mode": "oauth"}} and sign in to Sentry from the authorize_url; the agent then sees the organizations and projects that account can see.
The agent searches for issues first seen in the last 7 days and for issues marked regressed in the same window, across every project unless the prompt names some. For each it reads the issue's counts (events and users affected), the release it first appeared in, the environment, and the latest event's stack trace. It ranks the list by users affected, since a crash that hits many people once outranks a noisy error from one script.
Grouping is by root frame: the deepest in-app frame of each stack trace, the first line that is your code rather than a library. Issues that share that frame are often one bug that Sentry fingerprinted several ways, such as the same null access reached from three routes. The agent puts them in one group and keeps the separate issue links under it.
For each group it writes one line on the likely cause, read from the stack trace and the error message: the variable that had no value, the call that timed out. It suggests an owner from the file path in the root frame, using the code owners rules Sentry has for the project when the server returns them and otherwise naming the directory. The prompt says read only, so it resolves, assigns, ignores and comments on nothing, and writes triage.md in its sandbox.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Sentry connection to find issues first seen or regressed in the last 7 days across all projects. For each, read its users affected, event count, first release, environment and latest stack trace. Write triage.md: issues ranked by users affected; issues sharing the same deepest in-app frame grouped together with each issue linked; for each group a one-line likely cause from the stack trace and error message, and a suggested owner from the root frame's file path. Read only: resolve, assign, ignore or comment on nothing.",
"connections": [
"sentry"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The session returns triage.md as an artifact. The top of the file is a ranked table: group, users affected, events, first release, likely cause and owner. Below it, each group lists its Sentry issues with links and the root frame they share, so an engineer can open the issue and the file in one step.
Every search and event read is in the session's transcript, so a disputed grouping can be checked against the stack traces the agent read. Before assigning from the list, the on-call or lead checks the likely causes on the top groups (they are readings of a trace, not a debugged answer) and confirms owners where the path does not make ownership obvious.
Run it on every Monday morning
An automation with a schedule trigger in a Project runs this weekly, with a cron such as 0 9 * * 1 and the team's timezone. Each run looks back exactly 7 days, so consecutive reports do not overlap and a regression shows up the week it happened.
With a webhook URL on the key, Rush POSTs run.completed when the turn ends with the session_url. Your server can read the session and post the table to the engineering channel. The top group can go straight into another run, one with the repository as a resource, that tries a fix and opens a pull request.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A Sentry inbox sorted by event count puts the noisiest error first, not the one that hurt the most people, and spotting that three issues are one bug means reading every trace. The agent reads them all in its own sandbox each week, groups by the frame that matters, and hands back a list sorted by impact.
Every claim in the report traces to an issue and event the agent read, kept in the session's transcript, and the run changes nothing in Sentry. Teams with several Sentry organizations can run one session per organization at once, up to the key's concurrent run limit.
Frequently asked questions
Will it resolve or assign issues in Sentry?
No. The prompt says read only, and the transcript lists each tool call, so you can check. Connecting with a Sentry member account that cannot resolve issues makes it a hard limit.
How good is the likely cause?
It is a reading of the stack trace and error message, useful for routing and for deciding what to look at first. It is not a debugged root cause. A follow-up run with the repository can check the code and confirm or reject it.
Can I limit it to one project or environment?
Yes. Name the projects or the environment, such as production, in the prompt. The agent adds them to its issue searches, and the report covers only those.