# Investigate a Sentry Error Spike in a Rails App Yes. An agent reads the Sentry issues new in your latest Rails release, diffs that release against the last one, and names the commit most likely to blame. [Run this on Rush](https://cloud.getrush.ai/run/investigate-sentry-spike/rails/), in a Project that has your repository. ## What the agent does The agent opens Sentry through the connection the request names, finds the latest release and pulls the issues that are new in it or whose event rate rose after it. For each it reads the backtrace, whether it came from a web request or a background job, the controller and action or the job class, and the tags. In a Rails app that split matters: a spike in a Sidekiq job and a spike on a page are found in different parts of the code and fixed differently. It clones the repository into its own cloud sandbox and reads how errors reach Sentry. In an app like codetriage/CodeTriage, `Gemfile` pins Rails `8.1.3.1` and loads `sentry-ruby` and `sentry-rails`, and `config/initializers/sentry.rb` sets the DSN from `SENTRY_DSN`, breadcrumbs from `active_support_logger` and `http_logger`, excludes `Sidekiq::Shutdown`, samples 10% of traces, and sets no `release`, so the release comes from the deploy environment. `ApplicationController` calls `Sentry.set_user` with the user's id and GitHub name on every request, which lets the agent tell whether one account or many are affected. It notes that `app/jobs/sentry_job.rb` defines a `SentryJob` nothing in the app enqueues, so events are sent directly rather than through Sidekiq. Then it diffs the two releases with `git log` and `git diff` between their tags or SHAs and maps each issue to the changed code on its path. CodeTriage runs its background work as Active Job on Sidekiq (`config.active_job.queue_adapter = :sidekiq` in `config/application.rb`, the `worker` line in `Procfile`), so a job error leads to a class like `PopulateIssuesJob`, which pages through a repository's GitHub issues, or `SendDailyTriageEmailJob`. The `release` line in `Procfile` runs `rake db:migrate` on every deploy, so the agent also reads any migration in the range, such as the recent ones that change ids to `bigint`, because a migration that runs ahead of code still expecting the old shape is a common cause of a spike right after deploy. Where a test can show the bug, the agent runs the Minitest suite in the sandbox the way the repository's CI does, `bin/rake test` against Postgres, on both releases. It writes a report naming the most likely change, the evidence from Sentry and the diff, and the fix. It does not change code, push, open a pull request or touch the Sentry issues. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "codex", "input": "Errors rose after the latest release. Through the Sentry connection, find the issues that are new or grew in that release, diff the release's commits against the previous release in this repository, and write a report naming the most likely change, the evidence for it and the fix. Do not change code.", "connections": [ "sentry" ], "resources": [ { "url": "https://github.com/your-org/your-app" } ] } ``` 1. **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. 2. **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. 3. **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 What comes back is a Markdown report attached to the session as an artifact. It lists the releases compared, then each new or grown issue with its Sentry link, its source (controller action or job class), counts and first-seen time. The main finding names the commit: SHA, message, the lines it changed, the backtrace frame that lands in them, and, when a migration is involved, the schema change and the code that still expects the old schema. A fix section gives the change in words and as a short diff where it fits, plus the Minitest case that would have caught it. If the agent ran tests, the command and output are in the report, and every Sentry query, git command and test run is in the session's transcript. A reviewer confirms the frame against the quoted lines in Sentry and chooses between rolling back and fixing forward. Jobs that failed in the meantime may need retrying from Sidekiq once the fix ships; the report lists which job classes were affected. A follow-up to the same session can ask the agent to open the fix as a pull request. ## Run it on every error spike after a deploy A Sentry alert rule on new issues in the latest release, or on a jump in error rate, can call a handler on your server that sends this request. If you deploy with a release phase, the handler can also run a few minutes after each deploy and start a run only when Sentry shows new issues. Set a webhook URL on the API key and Rush POSTs `run.completed` when the report is ready; your handler links it from the deploy notification so the person who shipped the release sees it first. ## Why run it on Rush? An error spike in a Rails app can sit in a controller, a job, a mailer or a migration, and finding it means holding Sentry, the diff and the code in view at once. The agent does that in its own sandbox with Ruby, Bundler and Postgres available, so it can run the test suite on both releases without disturbing anyone's local database or a shared staging app. Each claim in the report comes with its evidence: Sentry links, commit SHAs, file and line, test output. The session's transcript records every step, and two incidents on the same day get two independent runs. ## Frequently asked questions ### Does it cover errors from Sidekiq jobs as well as web requests? Yes. sentry-rails reports exceptions raised in Active Job, and the agent follows a job's backtrace to the job class and the code it calls. The report says for each issue whether it came from a request or a job. ### What if the spike was caused by a migration? The agent reads every migration in the release range and checks the code that touches those tables. When the migration and the code disagree, such as a renamed column still read by an older query, the report names both and suggests the order of fixes. ### How does it connect to Sentry? Through Sentry's MCP server, connected once and named in the request's `connections`. The run can use only the connections it names. ### Will it retry failed jobs or resolve the Sentry issues? No. It only reads Sentry and the repository and writes a report. Retrying jobs and resolving issues stay with your team.