Skip to main content

Buyer guide

Seer Autofix Workflow Playbook: Root Causes Engineers Act On

Connect repositories and supply Seer's telemetry. Set where automation stops and measure how many pull requests merge.

Reading time
3 min read
Sources
10 cited
In this piece
Seer+11 Mixed

Seer pays off when engineers act on its root cause and avoid redoing the investigation. Connect each Sentry project to every repository its errors pass through, and set how far automation runs on each project. Have an engineer check the diagnosis before Seer writes code, then track how many of its pull requests merge.

When you need this

  • Your Sentry issue backlog grows faster than engineers triage it.
  • Engineers rebuild the same root cause from stack traces and traces by hand on every issue.
  • You are turning on Seer automation and need to decide where it stops.

Evaluation criteria

  1. Connect the right code

    Which repositories can Seer read for each project?

    Look forConnect each Sentry project to its repositories in Seer's project settings. Include the backend services its frontend calls, so Seer can follow a trace across repositories. Seer supports GitHub.com and GitLab.com only, and each repository can override its default branch. In June 2026, Seer's settings limited a project to 8 repositories. A Finverse developer who had connected 12 GitLab repositories to one project could not disconnect any of them until Sentry fixed that bug on June 16, 2026.

  2. Send the telemetry Seer reads

    What does Seer need from each project?

    Look forSend traces and profiles along with logs, as Sentry recommends, and upload source maps for minified JavaScript. Seer reads the rules files of Cursor, Windsurf, Cline, and Claude Code, and Sentry lists AGENTS.md and CLAUDE.md as supported. Seer's fixes then follow the conventions your coding agents already use.

  3. Set the stopping point

    How far does automation go without a person?

    Look forSeer runs on its own only for issues with 10 or more events in the last 14 days and a high enough fixability score. Set each project to Stop after Root Cause, Stop after Plan, or Stop after PR Drafted. The Zcash Foundation's plan for a Seer pilot on Zebra stops at root cause or plan. An automatic fix for a crash that a peer can trigger would disclose the vulnerability in its public repository.

  4. Check the diagnosis first

    Who reads the root cause before code is written?

    Look forAn engineer reads Seer's reasoning before choosing Code It Up. Seer asks for input when it lacks context. The engineer can remove plan steps or add instructions, such as a regression test for the original error.

  5. Iterate on the pull request

    How does feedback reach Seer after it opens a pull request?

    Look forOn GitHub, Seer pushes follow-up commits when CI checks fail. It also answers comments that start with @sentry and comments from reviewers with write access, including bots that leave inline comments. Check its output for problems specific to your repository. One pnpm team deletes by hand the package-lock.json that Autofix adds to every pull request.

  6. Measure what merges

    Is Seer's work landing?

    Look forCount the root causes engineers accept each month. Track merged Seer pull requests apart from those closed without merging or left open. Of the 3,781 public Seer pull requests GILD counted, teams merged 44% and closed 25% without merging. The other 30% were still open, 926 of them more than 30 days old.

Questions to ask vendors

  1. Which projects send traces, logs, and source maps, and which send errors only?
  2. Which repositories does each project's code span, including the backend services behind its frontend?
  3. What stopping point does each project start with, and what result moves it further?
  4. Who owns open Seer pull requests, and when are stale ones closed?
  5. How do we record whether an engineer accepted Seer's root cause?

Red flags

  • Every project set to Stop after PR Drafted on the first day.
  • Frontend projects connected without the backend repositories their errors come from.
  • No owner for open Seer pull requests, so they accumulate.
  • Minified JavaScript in production without uploaded source maps.

Products in this piece

Sources

Official documentation
5
Public source
5
  1. Sentry docs: AutofixOfficial documentationdocs.sentry.io
  2. Sentry docs: SeerOfficial documentationdocs.sentry.io
  3. Sentry blog: Seer, the Sentry MCP and CLI, or your own coding agent (Oct 2, 2026)Official documentationblog.sentry.io
  4. Sentry docs: GitHub integrationOfficial documentationdocs.sentry.io
  5. Sentry docs: GitLab integrationOfficial documentationdocs.sentry.io
  6. Zcash Foundation Zebra issue #11635: pilot Seer root cause analysis without automatic pull requests (Oct 9, 2026)Public sourcegithub.com
  7. getsentry/sentry issue #117489: Autofix repository limit (Jun 12, 2026)Public sourcegithub.com
  8. getsentry/sentry issue #125174: Autofix lockfile generation (Sep 22, 2026)Public sourcegithub.com
  9. GitHub search: pull requests opened by the Seer GitHub app (queried Oct 12, 2026)Public sourcegithub.com
  10. GitHub search: pull requests opened by the Sentry GitHub app (queried Oct 12, 2026)Public sourcegithub.com