How do I find out which deploy introduced a new production error?
Tag every error event with a release name, preferably the git commit SHA, and record each deploy from CI. Then compare the issue's first-seen time with the deploy time, check whether it is new or a regression, and use the stack frames with git log and git blame to find the change. Roll back or switch off the feature flag.
Why it happens
An error report tells you what failed and where, but not which change made it fail. Between two deploys there may be a dozen merged pull requests, a dependency bump and a config change, and the bug may sit in code that was written months ago and only now reached by a new caller. Without a record of what version was running when each error happened, the only evidence is timing, and timing is easy to misread: a nightly job, a traffic peak or a cache expiry can all produce a spike that looks like a deploy.
The fix is to make the question answerable by data. If every event carries the name of the build that produced it, an error tracker can list which releases an issue has appeared in, show the first release that produced it, and tell you whether an issue that you had fixed has come back. If the tracker also knows the commits in each release, it can match the files in the stack trace to recent commits that touched them.
Even with perfect tagging the result is a lead, not a verdict. The first release where an error appears is the first release where it was seen; the cause might have been in an earlier release that was never exercised in that path. Treat the output as a short list of commits to read, and confirm by reproducing the error or by rolling back and watching it disappear.
How to find which deploy introduced an error (works with any error tracker that supports releases)
Tag every event with a release, using the commit SHA
Pass a unique build identifier to the SDK as release when it initializes. The git commit SHA is the best choice because it ties the event to an exact commit with no extra mapping. Sentry's documentation notes that setting the release name tags each event with it, and that releases can also be created automatically the first time an event with that release arrives (Sentry docs, read 2026-11-13). Set the same value in the build and at runtime, and include an environment so staging and production are separate.
Sentry.init({ dsn: process.env.PUBLIC_DSN, release: process.env.GIT_SHA, environment: 'production', });Create the release, attach commits and record the deploy from CI
In the pipeline, create the release, associate the commits and then record a deploy for the environment. The commit step lets the tracker compare commits between releases, and the deploy step stores the time the release went live, which is what you compare against first-seen later. Sentry's sentry-cli documents releases new, releases set-commits with the --auto flag, releases finalize and deploys new --release with an environment (sentry-cli release management docs, read 2026-11-13). Run these before traffic moves to the new version.
sentry-cli releases new <sha> sentry-cli releases set-commits <sha> --auto sentry-cli releases finalize <sha> sentry-cli deploys new --release <sha> -e productionCompare when the issue was first seen with the deploy time
Open the issue and read its first-seen time and the release on its first event. If the first event is within minutes of a deploy to production and carries that deploy's release, that deploy is your prime suspect. If the first seen is hours after a deploy, look instead at what else started then: a traffic change, a scheduled job, a feature flag, a third-party outage. Check the release of the first event, not only the time, because rolling deploys and cached clients mix versions for a while.
Decide whether it is a new issue or a regression
A new issue has never been seen before, so look at the changes in the release that touch the code in its stack trace. A regression is an issue you had marked resolved that has returned, so look at the release that reintroduced it, and at the fix you made earlier, which may have been incomplete. Treat these differently: a regression usually points to a revert, a bad merge or an incomplete fix, while a new issue points to new code or a new input.
Read the stack frames and ask git who changed those files
Take the in-app frames from the top of the stack trace, which are your files rather than library code. List the recent commits that touched each file, then look at who changed the specific lines in the stack frame. Read the diffs, not only the messages: the cause is often in a helper that was changed in a commit with an unrelated title.
git log -n 5 --format='%h %an %ad %s' -- src/checkout/applyDiscount.ts git blame -L 80,95 src/checkout/applyDiscount.ts git show <commit> -- src/checkout/applyDiscount.tsMeasure impact, then roll back or switch off the flag
For an app that reports sessions, compare the crash-free session and user rates of the new release with the previous one: a drop is the clearest evidence that the deploy made things worse. If the cause is confirmed or the impact is high, the quick remedy is to roll back to the previous release or turn off the feature flag that exposes the change, then fix forward on a branch. Mark the issue resolved only after a release containing the fix has been running, so that if it returns it is flagged as a regression.
| What you see | Likely meaning | What to do next |
|---|---|---|
| First seen within minutes of a deploy, on that release | The deploy introduced it or exposed it | Diff the release, check commits that touch the stack frame files |
| First seen hours after a deploy, on older releases too | Not the deploy: input, traffic, dependency or schedule | Check what else started at that time |
| Issue was resolved and is back on a newer release | Regression: incomplete fix, revert or bad merge | Compare the fix commit with the release that brought it back |
| Appears on several releases at once | Long-standing bug reached by a new path | Look at what changed in callers, not the failing function |
| Crash-free rate drops for one release only | That release has a crash-level bug | Roll back or disable the flag, then investigate |
The release, commit and deploy behaviour comes from the Sentry JavaScript release and sentry-cli documentation (docs.sentry.io, read 2026-11-13); the interpretation column is the author's reasoning.
When to use Bugsly
Bugsly accepts the same release workflow: set SENTRY_URL to https://bugsly.dev, an auth token, your organization and project, and run sentry-cli releases new, set-commits and deploys new as shown above. With the GitHub integration connected, Bugsly also shows suspect commits for an issue: it ranks recent commits that touched the crash-site files and lists up to 5. Errors reported again after being resolved are flagged as regressions.
For apps that send sessions, the get_crash_free tool returns the crash-free sessions and users percentages for a number of days. It returns null until the SDK sends sessions, so enable session tracking in the SDK first. list_issues can sort unresolved issues so that you can start with the newest ones after a deploy. Suspect commits are a ranking by file overlap, not proof; read the diff before you blame anyone.
When Bugsly is not the right answer
If your code is not on GitHub, the suspect commits feature does not apply, because Bugsly integrates with GitHub only. You still get release tagging, deploys and regression flagging, and the git log and git blame commands above give you the same lead by hand.
If you need to know exactly which pull request to roll back across many services, or run automated progressive delivery with automatic rollback, use your deployment platform or a feature flag service for that; an error tracker tells you the release is bad, but it does not roll it back.
Ask your AI assistant to do it
With the Bugsly MCP server connected (https://bugsly.dev/api/mcp; setup for ChatGPT, Claude, Cursor and Gemini CLI is on /mcp), paste this. The assistant reads first and reports back; you decide what happens next.
Assign to Bugsly: use list_issues to find the newest unresolved issues in my project, then get_issue on the top 3 and tell me the release on each first event, whether it is a new issue or a regression, and the suspect commits if there are any. Then use get_crash_free for the last 7 days and say whether it is null. Do not resolve or ignore anything; show me what you found so I can approve the next step.
Frequently asked questions
What should I use as the release name?
The git commit SHA, or a version string that maps to exactly one commit. It must be identical in the SDK and in the commands you run in CI, otherwise events and commits will not line up.
Why does an issue show on the release before the deploy?
Usually the bug was already there and the new release only exposed it, or users with a cached older version are still running it. Check the first event's release, not only the time.
How soon should I record the deploy?
Before traffic moves to the new version, or immediately after. The deploy time is what you compare an issue's first-seen time against, so a late or missing deploy record makes the comparison misleading.
Does crash-free rate work for a web backend?
Only if the SDK sends sessions. Without sessions the rate has no data and shows as null, so rely on issue counts per release instead.
Sources
- Sentry docs: Releases & Health for Browser JavaScript (read 2026-11-13)
- Sentry docs: sentry-cli release management (read 2026-11-13)
Related
- Catch broken releases before users do
- Minified stack traces and source maps
- AI opens a pull request to fix an error
- Integrations
- All problems and solutions
Sentry is a trademark of its owner; Bugsly is not affiliated with or endorsed by Sentry. “Sentry-compatible” only means Bugsly accepts events sent by Sentry's open SDKs.