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

Connecting Sentry to GitHub is what unlocks all the “who changed what” magic: suspect commits, pull request links on issues, and Seer’s AI code review on PRs. Once wired up correctly, you can go from a production error to the exact commit and PR that likely introduced it, and push a fix through without leaving your normal GitHub workflow.

Quick Answer: Install the GitHub integration in Sentry, grant it access to the right repos, and make sure your Sentry releases are associated with Git SHAs. That lets Sentry surface suspect commits, link issues to pull requests, and power Seer’s AI code review on GitHub PRs.

The Quick Overview

What It Is: A first‑class Sentry ↔ GitHub integration that ties Sentry issues to commits, branches, and pull requests in your GitHub or GitHub Enterprise org.
Who It Is For: Engineering teams using GitHub who want production errors linked directly to the code changes and PRs that caused them.
Core Problem Solved: Triage takes too long when errors, code, and reviews live in separate systems. Sentry + GitHub connects issues to commits and PRs so you can see who broke what and ship fixes faster.

How It Works

At a high level, Sentry’s GitHub integration does three things:

Imports commit metadata so Sentry can identify Suspect Commits for each issue.
Connects Sentry issues to GitHub pull requests, branches, and files.
Enables Seer by Sentry to run AI code review checks directly on your GitHub PRs using real Sentry context.

Under the hood, it looks like this:

You install and authorize the Sentry GitHub app (or GitHub Enterprise app) with access to the repos that matter.
Your CI/deploy process tells Sentry about each release (including the commit range / SHAs).
When a new error or performance regression shows up, Sentry compares the event’s release with the associated commits to highlight suspect commits and PRs. If Seer is enabled, it also uses that context to review the PR.

Below is the step‑by‑step setup so Sentry can show suspect commits and link issues to PRs reliably.

Step 1 – Install the Sentry GitHub Integration

You do this once per Sentry organization.

In Sentry:
- Go to Organization Settings → Integrations.
- Find GitHub (or GitHub Enterprise, if self‑hosted).
- Click Install or Configure.
Authorize in GitHub:
- Sentry will redirect you to GitHub to install the app.
- Choose the GitHub organization and repositories Sentry should access.
  - For suspect commits + PR linking, Sentry needs access to the repos where your app code lives (not just infra).
- Approve the requested permissions (repo metadata, PRs, commits, etc.).
Confirm in Sentry:
- Back in Sentry, the GitHub integration should now show as Installed.
- If you use multiple GitHub orgs, repeat for each org you want tied to Sentry.

Tip: Start with the minimum set of repos you actually deploy. You can always expand access later.

Step 2 – Link GitHub Repos to Sentry Projects

Next, Sentry needs to know which GitHub repo corresponds to which Sentry project.

In Sentry, go to Project Settings → Repositories or use the Integration → GitHub → Configure screen.
Click Add Repository (if Sentry hasn’t auto‑discovered it).
Select the appropriate GitHub repository.
Confirm it’s associated with the correct Sentry project(s).

Once this mapping is in place, Sentry can:

Show commit lists and PRs on the project’s Releases page.
Match file paths in stack traces to files in the GitHub repo.
Attribute commits to owners (via CODEOWNERS / Ownership Rules).

Step 3 – Configure Releases with Git SHAs

Suspect commits only work if Sentry knows which commits shipped in each release. That means your release data needs to include Git metadata.

At minimum, make sure your deployment pipeline does this for each release:

Create a Sentry release with a commit or version identifier:
- Sentry SDKs or the CLI typically use a release identifier like:
  - my-service@1.2.3 or
  - a Git SHA (e.g., my-service@f3c9a1b).
Associate commits with the release:
- Use the Sentry CLI or API to tell Sentry which commits are in that release, for example:
  - From your previous deploy SHA to the current deploy SHA.
- This is what lets Sentry say: “This issue first appeared in release X, which includes commits A–Z.”
Deploy tracking (optional but highly recommended):
- Mark a release as deployed to an environment (production, staging, etc.).
- That way Sentry can show “First seen in release X” and tie errors to real deploys.

When new events come in:

Sentry looks at the release on the event.
It looks at the commits associated with that release.
It highlights Suspect Commits—the most likely commits that introduced the issue.

Step 4 – Enable Ownership Rules / CODEOWNERS (Optional but Powerful)

Once GitHub is connected and releases are wired up, you can go further with ownership:

Import or define CODEOWNERS from GitHub so Sentry knows who owns which paths.
Set Ownership Rules in Sentry to map file paths, tags, or URLs to teams.

Result:

New issues route directly to the right team.
Suspect commits show with the author, and Sentry can auto‑assign issues to the right person or team.
Linked PRs and commits are visible right where you triage.

Step 5 – Link Sentry Issues to GitHub Pull Requests

With the integration and releases in place, issue ↔ PR links come in a few ways:

Automatic PR linking via releases
- If your release payload includes PR information or Sentry can infer it from commits, Sentry will show:
  - Linked pull requests on the Release detail page.
  - Linked PRs on related issues.
Smart linking from commit messages
- If your commit messages reference issues or PR IDs consistently (#123, etc.), Sentry can help surface those references alongside suspect commits.
Manual linking (when needed)
- From a Sentry issue, you can:
  - Click through to the Suspect Commit.
  - Hop directly into the corresponding PR in GitHub.
- Or you can create a GitHub issue from a Sentry issue if you prefer bug tracking in GitHub Issues instead of a PM tool.

Once connected, the usual flow looks like:

Sentry flags a new issue in production.
You open the issue and see:
- Suspect commits with authors.
- Linked pull requests that introduced the change.
- Ownership and history.
You click through to the PR, fix the bug, merge, deploy, and watch the issue resolve.

Step 6 – Turn On Seer for AI Code Review (Optional but Recommended)

If you want AI to help review your PRs using Sentry data, you’ll also need to enable Seer.

Enable Seer in your Sentry org
- Seer is Sentry’s AI debugger and is purchased as an add‑on.
- Pricing: $40 per active contributor, per month, for unlimited use.
- Configure Seer Settings in your organization.
Make sure the GitHub integration is installed
- AI code review is currently available only on GitHub and GitHub Enterprise.
- Sentry uses the same GitHub connection you set up for suspect commits and PR links.
How AI code review works on GitHub
- 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 issues, you’ll see a 🎉 which means no errors detected.
  - If it does find potential problems, Seer leaves a review comment with:
    - Highlighted code,
    - Details about the issue,
    - Suggestions for how to fix it.

Because Seer is connected to Sentry context, it doesn’t just look at static code; it knows:

How your code behaves under heavy traffic.
What happens when multiple services are interacting.
Where production errors and performance issues have shown up before.

That’s what makes the PR feedback grounded instead of generic.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
GitHub Integration	Connects Sentry to your GitHub/org repos and PRs	Centralizes error, commit, and PR context in one debugging workflow
Suspect Commits	Identifies the commits most likely to have introduced an issue	Cuts triage time by pointing directly to the relevant code changes
Issue ↔ PR Linking	Shows related pull requests and releases on Sentry issues	Lets you jump from issue to PR to fix without manual cross‑referencing
Seer AI Code Review (GitHub)	Reviews PRs using Sentry context and posts comments in GitHub	Catches likely production issues before merge
CODEOWNERS / Ownership Rules	Maps files and paths to owners based on repo rules	Automatically routes issues and suspect commits to the right people

Ideal Use Cases

Best for teams deploying multiple times per day: Because suspect commits and PR links make it obvious which deploy broke what, even when release cadence is high.
Best for services with multiple owners and microservices: Because Ownership Rules + suspect commits clarify which team owns the fix across many repos and services.

Limitations & Considerations

Requires GitHub or GitHub Enterprise: AI code review is currently only supported on GitHub and GitHub Enterprise. If your repos live elsewhere, you’ll still get suspect commits (via other VCS integrations), but not Seer’s GitHub PR checks.
Release metadata is not optional for good results: Without properly configured releases with commit data, Sentry can’t reliably identify suspect commits or relate issues to the correct PRs. Make sure your CI/deploy process reports releases to Sentry.

Pricing & Plans

The core GitHub integration (suspect commits, issue ↔ PR linking) is available across Sentry’s standard plans. You pay based on your telemetry volume (errors, spans, replays, etc.) and organization plan.

For AI‑assisted debugging and AI code review:

Seer Add‑On:
- Priced at $40 per active contributor, per month.
- Includes unlimited use of Seer features, including AI code review on GitHub PRs.

You can start on a standard Sentry plan, then add Seer when you’re ready.

Core Sentry Plan: Best for teams needing robust error monitoring, tracing, and GitHub‑backed suspect commits.
Core Sentry + Seer: Best for teams that want AI‑assisted debugging and PR review grounded in real Sentry context.

For the latest details, check Sentry’s pricing page when you sign up.

Frequently Asked Questions

Do I need Seer for suspect commits and PR links to work?

Short Answer: No. Suspect commits and issue ↔ PR linking work with the GitHub integration and proper release configuration. Seer is only required for AI code review and AI‑assisted debugging.

Details:
Suspect commits are driven by releases and commit metadata. As long as:

You’ve installed the GitHub integration,
Linked repos to the right projects,
And your CI/deploy process creates Sentry releases with commits,

Sentry will highlight suspect commits and show related PRs. Seer builds on that same context to provide AI code review and debugging, but it’s an optional add‑on.

How do I know the GitHub integration is working correctly?

Short Answer: You should see commits, releases, and (for new issues) suspect commits and PRs on your Sentry project. If those are missing, your releases or repo mapping need attention.

Details:
To verify:

Trigger a deploy that creates a Sentry release with commit data.
In Sentry, open Releases for your project.
Confirm you see:
- A list of commits for the release,
- A link to the GitHub repo,
- Any related pull requests.
Generate a test error after the deploy, and check the new Sentry issue:
- Look for “Suspect Commits” on the issue sidebar.
- Ensure the commit author and linked PR (if any) appear.

If you don’t see that:

Check the GitHub integration status under Organization Settings → Integrations.
Verify repositories are correctly linked to the Sentry project.
Confirm your release process is sending commit ranges to Sentry (not just a version string).

Summary

Connecting Sentry to GitHub is the key to seeing suspect commits and PR links directly on your issues. You install the GitHub integration, map repos to projects, and wire your CI/deploy pipeline to send releases and commit data to Sentry. From there, Sentry can pinpoint the commits likely responsible for an issue, show you the related pull requests, and—if you enable Seer—review your PRs in GitHub using the same production context.

When production breaks, you no longer have to manually dig through commits and PRs to find the culprit; Sentry brings the code and the error together for you.

Next Step

Get Started