How can I get production stack traces with the exact release/version and commit that introduced the error?

Most teams don’t struggle to see production stack traces—they struggle to tie those traces back to the exact release and commit that introduced the error so they can fix it quickly and move on. With Sentry, you can connect every production error to a specific release, changeset, and owner, so you’re not guessing which deploy broke things.

Quick Answer: Use Sentry’s SDKs with release configuration, deploys, and source code integration. That way, every production stack trace is tagged with the exact release/version, linked to the commit(s) that shipped in that release, and routed to the right owner via features like Suspect Commits and Ownership Rules.

---

The Quick Overview

• What It Is: A workflow for capturing production stack traces, enriching them with release/version metadata, and connecting them to the exact commit that introduced the error.
• Who It Is For: Developers, SREs, and engineering leaders responsible for debugging production issues and owning releases.
• Core Problem Solved: Eliminates the “what changed?” guessing game by tying each production error to a precise release and commit, plus who’s most likely responsible for the fix.

---

How It Works

At a high level, you configure the Sentry SDK to send events (errors/exceptions, transactions, spans) tagged with a release identifier. You then tell Sentry what that release means in terms of commits and deploys. When an error hits production, Sentry groups it into an issue, attaches the complete stack trace, and associates it with that release and the commit(s) that landed in it. Features like Suspect Commits, Ownership Rules/Code Owners, and integrations with your VCS (GitHub, GitLab, Bitbucket, etc.) turn that into an actionable debugging path.

Here’s the typical flow:

1. Instrument your code and tag releases

   • Install and configure the Sentry SDK (for Python, JavaScript, Java, etc.).
   • Set a unique release value (e.g., my-service@1.2.3 or a commit SHA).
   • Optionally tag environment (production, staging) for clearer separation.

2. Connect releases to commits and deploys

   • Integrate Sentry with your source control and CI/CD.
   • Use Sentry’s release API or CLI to create releases and associate commits.
   • Mark deploys (e.g., “production deploy at 2026-04-12T10:12Z”) so Sentry knows when that release hit production.

3. Debug from stack trace → release → commit

   • When an error occurs, Sentry captures a full stack trace with local context (where language/runtime supports it—like Python).
   • The issue page shows the release and the exact commit range introduced since the previous release.
   • Suspect Commits and ownership rules help you identify who should fix it and what changed.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Release Tracking	Tags each event with a release identifier (version or commit SHA) and links it to deploys.	Lets you see exactly which version introduced a bug and when it went live.
Source Code & Commit Integration	Connects Sentry to GitHub/GitLab/Bitbucket and associates releases with commit metadata.	Turns “stack trace + version” into “these exact commits and files likely caused this error.”
Suspect Commits & Ownership Rules	Uses commit history and code ownership to surface who likely introduced the error.	Routes issues to the right people fast, cutting triage time from days to minutes.

---

Step-by-Step: Getting Stack Traces with Exact Release and Commit

1. Configure the Sentry SDK with a Release

In each service or app, configure the Sentry SDK and set the release and environment values. For example, in Python:

import sentry_sdk

sentry_sdk.init(
    dsn="https://<key>@o<org>.ingest.sentry.io/<project>",
    release="my-service@1.2.3",
    environment="production",
    traces_sample_rate=1.0,
)

Key points:

• release should uniquely identify what’s deployed:
  • Semantic version: my-service@1.2.3
  • Commit SHA: my-service@<git_sha>
• environment separates production, staging, etc., so you can see if an error is new to prod or started in another environment.

When an error occurs, Sentry sends an event with the full stack trace and these tags.

2. Link Sentry to Your Source Code and Commits

Next, connect your VCS and CI/CD so Sentry understands what is in a given release.

1. Connect your repository

   • In Sentry, connect GitHub, GitLab, Bitbucket, or your Git provider.
   • This lets Sentry map stack frames to files and commits.

2. Create releases programmatically

   • Use Sentry’s CLI or API from your CI pipeline to:
     • Create a release.
     • Associate commits.
     • Mark the deploy environment.

Example using the CLI in CI:

export SENTRY_AUTH_TOKEN=<token>
export SENTRY_ORG=<your-org>
export SENTRY_PROJECT=<your-project>
export RELEASE=my-service@1.2.3

sentry-cli releases new "$RELEASE"
sentry-cli releases set-commits "$RELEASE" --auto
sentry-cli releases deploys "$RELEASE" new -e production

What this gives you:

• A release entity listing the commits included.
• A deploy entry showing where and when that release reached production.
• A clean commit diff between releases, so Sentry knows “what changed” for each issue.

3. Capture Complete Production Stack Traces

When a production error occurs, the runtime SDK sends a detailed stack trace to Sentry.

For Python applications (as an example):

• Sentry captures the exception with complete stack traces, including:
  • File names and line numbers.
  • Function names and code snippets (where available).
  • Local variables in stack frames for prod errors, similar to your dev debugger.

You can:

• Filter and group Python exceptions intuitively to eliminate noise.
• Aggregate errors by HTTP request, hostname, app version, and more to see what’s new versus what’s a long-running issue.
• Answer questions like:
  • In which app release did this bug occur?
  • Is this regression tied to the latest deploy?

This same pattern applies across supported platforms (JavaScript, Java, Node.js, .NET, etc.), with language-appropriate stack trace capture.

4. See the Exact Release/Version for Each Error

In Sentry’s issue details view, you’ll see:

• The release and environment where the error occurred.
• Whether it’s a new issue for that release or a regression.
• First seen and last seen timestamps relative to your deploys.
• The stack trace with frames linked to your source files (with source maps/symbols where relevant).

This lets you quickly answer:

• Did this start in 1.2.3 or earlier?
• Is this only happening in production, or also in staging?
• Did the latest deploy make it better or worse?

5. Identify the Commit That Introduced the Error

With release + commits wired up, Sentry adds deeper insight on the issue:

• Suspect Commits: Sentry analyzes the stack trace and commit history to highlight the commit most likely to have introduced the error.
• Commit author & ownership: With Ownership Rules and CODEOWNERS integration, Sentry can suggest or auto-assign the issue to the right team or person.
• Release comparison: On the release page, you can see:
  • New issues introduced in that release.
  • Issues that regressed.
  • Performance changes (if you’re using Tracing and Profiling).

The practical flow when you open an issue:

1. Look at the stack trace to see where in the code it failed.
2. Check the release tag to confirm the version and deploy.
3. Inspect Suspect Commits to see which commit touched that code recently.
4. Use Assignees/Ownership Rules to route it to the right owner.
5. (If you use Seer) Let Sentry’s AI-assisted debugging use the stack trace, spans, commits, and logs to propose a root cause and potential fix.

6. Tie Stack Traces to Performance and User Impact (Optional but Recommended)

To avoid focusing on errors that don’t matter, pair error data with performance and user impact:

• Tracing & Spans: Capture transactions from frontend to backend to see how an error sits within a slow request or workflow.
• Session Replay: For supported platforms, link errors to replays to watch what the user did right before the stack trace fired.
• Logs & Profiling: Attach logs and profiling data to issues to see slow code paths and resource usage around the time of the error.

This doesn’t change the release/commit mapping, but it makes your debugging loop tighter: you see which commit caused the error and how badly it affected users or performance.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Release Tagging in SDKs	Adds a release and environment tag to every error, transaction, and replay.	You always know which version and environment an error came from.
Release & Deploy Management	Creates release entities, associates commits, and records deploys.	Connects “this version in production” to “this exact commit range.”
Stack Traces with Context	Captures stack traces with frame details; in Python, includes local variables in frames.	Lets you debug prod errors like you’re in your dev debugger, but with real user context.
Suspect Commits & Ownership Rules	Uses commit history and code ownership to suggest who introduced and should fix the issue.	Cuts triage time; issues go straight to the people who can actually fix them.
Source Maps/Symbols & Code Integration	De-minifies stack traces (JS) or symbolicates native stack traces and links them to your repo.	Turns unreadable stack traces into human-readable, clickable code locations.

---

Ideal Use Cases

• Best for teams shipping frequently to production: Because Sentry automatically associates errors with releases and commits, you can ship fast without losing track of which deploy caused what.
• Best for polyglot microservices environments: Because release tagging works per service and environment, you can see which microservice version introduced a cross-service failure and trace through the stack.

---

Limitations & Considerations

• You must set release consistently: If your release values are inconsistent across services or CI pipelines, Sentry can’t reliably connect errors to commits. Standardize naming like service-name@<git_sha> or service-name@<semver>.
• Commit linkage requires VCS/CI integration: Without connecting your repo and running sentry-cli releases (or the API), Sentry will still show stack traces and release tags—but you won’t get commit diffs or Suspect Commits. Invest a bit of CI wiring to unlock the full workflow.

---

Pricing & Plans

All Sentry plans can capture production stack traces and tag them with release/version. The main differences are in scale and governance.

• Developer Plan: Best for individual developers or small teams needing core error monitoring, tracing, and release tracking without heavy governance. You get defined quotas for events, spans, and replays, plus a limited number of dashboards.
• Team / Business+ Plans: Best for growing teams and organizations needing more volume, collaboration, and control. You get:
  • Higher or unlimited dashboard counts.
  • Advanced governance features on Business+ (SAML-based SSO, SCIM, audit logs).
  • Options to reserve volume and add pay-as-you-go budget so you can keep capturing production stack traces when traffic spikes.

Seer, Sentry’s AI-assisted debugging, is available as an add-on priced per active contributor if you want automated root cause analysis and fix suggestions based on your stack traces, spans, commits, and logs.

For detailed pricing, volume quotas, and plan comparisons, see: https://sentry.io/pricing

---

Frequently Asked Questions

How do I ensure every production error includes the correct release/version?

Short Answer: Set the release and environment in your Sentry SDK initialization and create releases via CI for every deploy.

Details:
In each service, initialize the Sentry SDK with a consistent release value (ideally tied to a commit SHA or semantic version) and your environment name. In CI, use sentry-cli or the API to:

1. Create the release (sentry-cli releases new).
2. Associate commits (sentry-cli releases set-commits --auto).
3. Register the deploy (sentry-cli releases deploys new -e production).

Once that’s in place, every error Sentry receives will carry the correct release tag and show up under that release’s page with commit context.

---

Can Sentry show me the exact commit that introduced a new production error?

Short Answer: Yes, when you connect your repo and CI, Sentry can highlight the likely suspect commit and author for each new issue.

Details:
By comparing the commit range between releases and analyzing the stack trace, Sentry’s Suspect Commits feature surfaces which commit likely introduced the error. Combined with Ownership Rules or CODEOWNERS, Sentry can:

• Suggest an owner based on who edited the affected files.
• Auto-assign issues in Sentry or when creating tickets in tools like Linear.
• Show you exactly which commit(s) touched the code paths in the stack trace.

This turns the question “Who broke production?” into a specific commit and author, backed by the actual code diff.

---

Summary

If you want production stack traces that tell you exactly which release and commit introduced an error, you need three things wired up: SDKs with release tagging, releases connected to commits and deploys, and source code integration. Sentry gives you that end-to-end: full stack traces (with local variables for Python and deep runtime context), precise release/version tagging, and commit-aware features like Suspect Commits and Ownership Rules.

The result is a faster debugging loop: open the issue, see the stack trace, see the release, see the commit, and route it to the right owner—all without spelunking through logs or guessing which deploy caused it.

---

Next Step

Get Started