← Back to Cookbook

Build a self-healing workflow with Seer

Let Sentry fix issues for you. Sentry captures issues with full context of your application, Seer pinpoints the root cause, and ships the fix as a pull request using Seer or the agent of your choice. All done automatically or with a human in the loop, whatever works for you.

Jump to recipe
Features
Seer ,  Error Monitoring ,  Tracing
Category Workflow
Time
20–30 minutes
Difficulty
Intermediate
Steps
4 steps

Before you start

SDKs & packages
  • Sentry SDK installed and reporting events in your app
  • Seer enabled for your project
Accounts & access
  • Sentry account with at least one project (org owner or admin role to enable Seer and install integrations)
  • A GitHub or GitLab hosted repository with your app's source code
Knowledge
  • Basic familiarity with Sentry issues, projects, and settings
  • Comfort reviewing and merging pull requests

1
Capture issues with rich context

A self-healing workflow only works when it's built on good context, and Sentry issues are full of it. But only if you set up your application to send Sentry the right info. Setting up the SDK is a good first step, but make sure you're sending more than bare errors.

Use the Sentry CLI init command or the Sentry MCP server with Agent Skills to instrument new or existing applications with the context your apps need:

What context Sentry captures on an issue

2
Enable Seer and connect your codebase

For Seer to move from describing a bug to fixing it, it needs to see the code.

To connect your source code to Sentry, head over to the Integrations tab in your Project settings. Sentry supports several Source Code Management integrations, but for Seer specifically there's an integration with GitHub and GitLab. To get started:

Seer overview

3
Let Seer diagnose the root cause

At this point, if you let Seer draft PRs for you, you're actually done. Congrats! 🎉

Seer will monitor your projects for issues, determine the fixability of those issues, and automatically generate PRs. But let's say you want to be more involved in the process. There are two ways you can interact with Seer to investigate issues and manually trigger a root cause analysis.

  • Autofix in Sentry UI - Open any issue in your Issues feed and press Start Analysis. This will kick off Seer's Root Cause Analysis, let you create a plan to fix it, and implement that fix using Seer or another agent
  • Seer Agent in Slack - If you've set up the Sentry Slack integration you can interact with the Seer agent using DMs or in threads. The Seer agent allows you to investigate issues, assign them to users, and even have Seer resolve issues for you.
How Seer does root cause analysis

4
The agents will take care of the rest

Once Seer has a root cause and solution, it can generate the fix and open a pull request in your connected repo, or hand the structured analysis off to a third-party coding agent like Claude Code, Cursor, or GitHub Copilot, which apply the change in your own environment.

How autonomous you want Seer to be is up to you. Turn on automation in Settings → Seer. and Sentry will trigger an Issue Fix automatically on issues that clear a fixability bar, so fixes show up without you having to kick them off by hand. You control how far it runs before pausing for a human:

  • Stop after Root Cause: Seer explains the issue but writes no code
  • Stop after Solution: Seer proposes a fix plan but doesn't open a PR
  • Stop after PR Drafted: Seer opens a pull request with the fix, ready for review
  • Hand off to a coding agent: send the root cause and solution as a structured prompt to Claude Code, Cursor, or another agent to apply in your repo or CI
Seer Issue Fix and automation settings

That's it.

Your issues fix themselves.

Sentry catches the bug, Seer explains why it happened, and a fix lands as a PR. Problem solved.

  • Captured issues in Sentry with the context Seer needs to reason: stack traces, traces, logs, metrics, and replays
  • Connected your codebase and enabled Seer for automatic root cause analysis
  • Let Seer diagnose the root cause of an issue, validate findings, and create a plan to fix it
  • Automated remediation with native pull requests or a handoff to a third-party coding agent

Pro tips

  • 💡 The more context you give to Sentry, the better the analysis and fix. Make sure you are instrumenting your application to send more than just errors to your Sentry projects.
  • 💡 Start with a conservative automation stopping point (Stop after Solution) while you build trust in Seer's diagnoses, then move to Stop after PR Drafted once the fixes look consistently good.
  • 💡 Treat a Seer-authored PR exactly like a human one: same review, same test run. The point is to skip the diagnosis toil, not the code review.
  • 💡 Use the Sentry MCP server for issues that touch code Seer can't see (private services, monorepo siblings) so your local agent can fill in the gaps. You can even call a Seer RCA from the MCP as part of this flow.

Common pitfalls

  • ⚠️ Skipping code mappings. If stack frames don't resolve to real files, Seer can't read the relevant code and its diagnosis degrades to guesswork.
  • ⚠️ Enabling full automation on a noisy project before tuning it. Without a fixability bar and event thresholds, you'll generate PRs for issues that aren't worth fixing.
  • ⚠️ Expecting a merge-ready PR on every issue. Some root causes are environmental or architectural, and Seer will say so, and that diagnosis is still the useful output.
  • ⚠️ Sending bare exceptions with no tracing, logs, or tags and expecting a precise fix. Rich context is the input the whole loop depends on.

Frequently asked questions

No. Even at its most autonomous, Seer stops at a drafted pull request. It never merges on its own. You choose the stopping point (root cause, solution, or PR), and a human always reviews and merges the change.

Instead of Seer opening the PR itself, it passes the root cause and solution as a structured prompt to a coding agent like Claude Code or Cursor. The agent applies the change in your own environment, useful when the fix needs to run tests, touch code outside the connected repo, or follow your local workflow.

When automation is enabled in Seer settings, Sentry triggers Issue Fix on issues that meet the criteria: 10 or more events, seen within the last 14 days, and a sufficient fixability score. You can tune these so the loop only runs on issues worth fixing.

For root cause analysis grounded in your code and for Seer to open pull requests, yes. Seer needs repository access and code mappings. You can still get context-based root cause reasoning without it, but native remediation depends on the codebase connection.

No. The Sentry MCP server is free and only reads data you already have in Sentry. It doesn't count against your event quota. Seer usage itself is billed separately; see Sentry's pricing for current Seer details.

What's next?

Seer: AI debugging

Seer is the AI debugger that uses Sentry context to flag breaking changes, automatically root cause issues in production, and fix what you missed.
Learn about Seer: AI debugging →

Error Monitoring

Resolve the errors that matter first. Sentry's error monitoring traces every issue to its root cause in code, complete with stack traces and breadcrumbs
Learn about Error Monitoring →

Catch bugs in PRs before they merge

Extend the loop leftward: have Seer review every pull request using real production error data, so defects are caught at review time instead of in production.
View recipe →

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.

Try Sentry for Free Explore our Sandbox