How do I connect Sentry to GitHub so it shows suspect commits and links issues to PRs?

Most teams connect Sentry to GitHub for one core reason: when production breaks, they want to see exactly which commit (and developer) likely caused it, and jump straight from a Sentry issue to the right pull request. That’s what features like Suspect Commits, Releases, and PR links are doing behind the scenes.

Below is the practical, step‑by‑step way to wire Sentry and GitHub together so you get:

Suspect Commits on issues
Linked pull requests and releases
AI code review with Seer commenting directly on your PRs (optional but highly recommended)

The Quick Overview

What It Is: A GitHub integration that lets Sentry use your commit and PR metadata to identify Suspect Commits, link issues to pull requests, and (with Seer) review code using real production context.
Who It Is For: Engineering teams deploying to production who want to connect “what broke” in Sentry to “what changed” in GitHub without manual detective work.
Core Problem Solved: Debugging incidents without knowing which commit caused them or which PR to fix, leading to slow triage and too many “anyone know what changed?” Slack threads.

How It Works

At a high level, Sentry uses three inputs to show Suspect Commits and link issues to PRs:

GitHub integration: Shares repo, commit, and PR metadata with Sentry.
Release & deployment data: Your CI/CD or manual release config tells Sentry which commits went out in which release.
Event + tracing context: When an error or performance issue happens, Sentry ties it back to the release and the commits that introduced it.

From there, Sentry can:

Show Suspect Commits in the issue details, based on when the bug first appeared and the files it touches.
Display linked pull requests and changesets directly in Sentry.
Power Seer’s AI code review so it can comment on PRs using real production context and surface errors before they merge.

The full workflow looks like this:

Connect GitHub to Sentry: Install the Sentry GitHub app or GitHub Enterprise app and authorize repos.
Configure releases and deploys: Tell Sentry about releases (via SDK, CLI, or CI) so it can map errors to commits.
Use issues + Seer in your workflow: Sentry groups events into issues, shows Suspect Commits and PRs, and (optionally) runs AI code review on new PRs.

Step 1: Install and configure the GitHub integration

You can wire this from either side—Sentry or GitHub—but doing it from Sentry keeps the workflow obvious.

1.1. Start the GitHub integration in Sentry

In Sentry, go to Settings → Integrations.
Find GitHub (or GitHub Enterprise if self‑hosted).
Click Install or Configure.

Sentry will prompt you to authorize the Sentry GitHub App in your GitHub organization.

1.2. Grant access to the right repositories

In the GitHub install flow:

Choose Only select repositories (recommended) or All repositories if you’re okay with that scope.
Make sure you include:
- Repos that contain the services you monitor with Sentry.
- Any shared libraries referenced in stack traces.

Sentry needs read access to code and metadata to:

Map stack trace file paths to GitHub paths.
Identify which commit last touched those files.
Show linked PRs and releases.

You don’t need to give Sentry write access to code; code changes happen through your normal GitHub workflow.

1.3. Confirm the integration in Sentry

Back in Sentry:

Under Settings → Integrations → GitHub, confirm:
- The GitHub organization is connected.
- The expected repositories are listed and enabled.
(Optional but useful) Enable:
- Automatic issue linking for PRs.
- Commit tracking for releases (more on that next).

Step 2: Set up releases so Sentry can track commits

Suspect Commits are only useful if Sentry knows which commits went out in which release. That’s what the Releases feature is for.

You need to:

Create releases in Sentry.
Associate them with specific commits (and ideally with deploys).

You can do this in a few ways.

2.1. Use Sentry’s release API or CLI in your CI

In your CI (GitHub Actions, CircleCI, etc.), add steps to:

Create a release using your Git SHA or version tag.
Associate commits with that release.
Mark the deploy when it goes live.

Example (pseudocode using CLI):

# Create a release
sentry-cli releases new "$GITHUB_SHA"

# Tell Sentry which commits belong to this release
sentry-cli releases set-commits "$GITHUB_SHA" --auto

# Mark the deploy
sentry-cli releases deploys "$GITHUB_SHA" new \
  -e production

Key point: set-commits --auto uses the GitHub integration to pull commits from your repo and connect them to the release, which is what powers Suspect Commits.

2.2. Use SDK-based releases

In addition to CI, configure the release in your Sentry SDK:

Sentry.init({
  dsn: 'https://examplePublicKey@o0.ingest.sentry.io/0',
  release: process.env.SENTRY_RELEASE, // e.g., GITHUB_SHA or version
  environment: process.env.NODE_ENV,
});

This ensures events include the release and environment fields, so Sentry can say:

“This error first appeared in release X.”
“That release includes commits A, B, and C.”
“Commit B is the Suspect Commit.”

2.3. Verify releases and commits are showing up

In Sentry:

Go to Releases.
Confirm that:
- New releases match your deploys (version or SHA).
- Commits and authors are listed under each release.
Click into a release:
- You should see commit history and linked PRs if GitHub is wired correctly.

Step 3: Enable and use Suspect Commits

Once GitHub and releases are configured, Sentry can start guessing who broke what.

3.1. How Suspect Commits work

Under the hood, Sentry looks at:

The time the issue started (first event).
The release that introduced it.
The files and frames in the stack trace.
The Git history of those files from GitHub.

Then it flags one or more commits as Suspect Commits—usually the commit that most recently touched the file and function in question.

In the issue details page you’ll see:

A Suspect Commits section with:
- Commit SHA + message.
- Author (the likely owner).
- Links to the commit and, if available, the PR in GitHub.

That’s the moment where you can skip guessing and just ping the right person.

3.2. Linking issues to PRs automatically

With the GitHub integration:

When you create a release from commits that reference PRs, Sentry can show those PRs in the Releases and Issues views.
If your CI/tags and GitHub integration are aligned, Sentry can automatically link:
- Issues → Releases → Commits → Pull Requests.

Make sure:

Your CI runs sentry-cli releases set-commits with --auto or equivalent.
Your Git author emails match Sentry user emails where possible (for better ownership mapping).

3.3. Linking Sentry issues from GitHub PRs

You have two options:

Manual linking via IDs:
Include the Sentry issue URL or ID in your PR description. Many teams standardize this (e.g., “SENTRY-1234” or direct URLs).
Workflow tools (e.g., Linear):
If you use Linear + Sentry, you can:
- Create a Linear issue from any Sentry error.
- Assign it, label it, and prioritize from Sentry.
- When the Linear issue is closed, it will automatically resolve the issue in Sentry.

This keeps the chain: Sentry issue → Linear ticket → GitHub PR → back to Sentry.

Step 4: (Optional) Turn on Seer’s AI code review for GitHub PRs

If you want Sentry to not only show Suspect Commits but also review new PRs for likely issues before they merge, enable Seer’s AI code review.

4.1. What AI code review does

Once the Seer by Sentry GitHub app is installed and configured:

Sentry automatically checks your PRs for errors the first time they’re set to “ready for review.”
If Sentry doesn’t find any issues, you’ll see a 🎉 in the PR comment.
If it does find something, you’ll see:
- Highlighted code in a PR comment.
- Details about the relevant error or risk.
- A suggestion for how to fix it.

Because Seer is connected to Sentry’s context, it doesn’t just read your diff; it knows:

How your code behaves under heavy traffic.
What happens when multiple services interact.
Which types of issues have historically mattered in production.

4.2. How to enable AI code review

To get AI code review working:

Configure Seer Settings in Sentry:
- In Sentry, go to Settings → Seer (or AI).
- Enable AI code review for your organization.
Install the Sentry GitHub integration (covered above):
- Make sure the Seer GitHub app is installed where your PRs live.
Confirm in the docs:
- AI code review is currently only supported on GitHub and GitHub Enterprise.
- AI code review is available everywhere (no region limitation).
- It’s part of Seer, which is priced at $40 per active contributor per month, with unlimited use.

From there, just open a PR, set it to “ready for review,” and let Seer do its thing.

Troubleshooting: If Suspect Commits or PR links aren’t showing

If you’ve connected GitHub but don’t see what you expect, check these:

Releases missing?
If releases aren’t in Sentry, there’s nothing to map commits to. Verify:
- CI is calling sentry-cli releases new and set-commits.
- SDK is sending release and environment.
No commits in releases?
Make sure:
- set-commits is run with Git available in CI.
- The GitHub integration has access to the repo.
- You’re not using a shallow clone without history when Sentry tries to fetch commits.
Authors not mapped to users?
If Ownership Rules and Suspect Commits don’t show clear owners:
- Align Git commit emails with Sentry user emails where possible.
- Use Ownership Rules or Code Owners in Sentry to route issues.
AI code review not triggering on PRs?
- Confirm the Seer GitHub app is installed in the right org/repos.
- Ensure the PR is set to “ready for review” (that’s the trigger point).
- Make sure you’ve enabled Seer in Sentry and have Seer seats assigned.

Summary

Connecting Sentry to GitHub is what turns raw error data into a clear “who broke it and where” workflow:

The GitHub integration gives Sentry access to repos, commits, and PRs.
Releases and deploys connect production issues to the exact changeset.
Suspect Commits and linked PRs show you which commit likely introduced the issue and who should fix it.
With Seer’s AI code review, Sentry can also flag likely production issues directly on your GitHub PRs, using the same production context.

Wire those together once, and every new incident comes with a shortcut: straight from an issue in Sentry to the commit, the PR, and the person best able to fix it.

Next Step

Get Started