A deploy goes out. An hour later someone notices the error count is up. The question that matters is simple: did the deploy do this?
The tracker's answer to that question is usually missing. Most teams install an error tracker's SDK and stop there, without ever telling it what a "release" is. Every issue then looks the same age, and every error looks like it has always been happening. "Did this start with the deploy" turns into someone manually cross-referencing timestamps against a deploy log in another tab.
The rest of this post walks through what release tracking actually does, honestly stated. It covers what release tracking can tell you for certain and what it can only suggest, using Sentry's documented approach as the reference point. Then it shows how the same idea works in RealUptime Errors.
What is a release in an error tracker?
A release is a string, nothing more. It can be a git SHA, a semantic version, a build number, or whatever your deploy pipeline already produces. The tracker attaches that string to every event it receives while that version is live. Events then form groups by version instead of one undifferentiated pile.
Once that attachment exists, three questions become answerable:
- Is this issue new in the current release, or did it exist before? "First seen in v128" is a fact about the data, not a guess, once every event carries its release string.
- Did an issue's rate change between releases? A steady trickle of an error is a different signal from one that spikes the moment a new version goes live.
- Which release fixed something? An issue with a last-seen event in v127 and nothing since v128 shipped is evidence the fix landed, even if nobody explicitly closed the issue.
None of this requires the tracker to understand your code. It needs two things from you. First, send the release string with every event, which is one configuration line in most SDKs. Second, tell the tracker when a release deploys, which is one API call from CI.
Can a tracker tell you which commit caused an error?
A tracker can narrow down where to look, but it cannot honestly say which commit caused an error. The claim tips over at the point where evidence becomes a verdict.
Sentry's documentation describes what it calls a suspect commit. For each in-app frame in a stack trace, working top-down, Sentry checks blame data to find the most recent commit that touched that file and line. It treats that commit as suspect if it is under a year old.
Suspect commits are a genuinely useful way to narrow down where to look. Read carefully, the feature is also a correlation: the last person to touch a line, not necessarily the person whose change is wrong. It is evidence a human should look at, not a verdict.
The distinction matters because "suspect commit" as a UI label reads like an accusation, and the underlying signal is narrower than it sounds. A formatting pass, a rename, or an unrelated refactor that touches the same line is enough to make blame point at the wrong commit. Treating "suspect commit" as "this commit caused it" skips the step where someone actually reads the diff.
What RealUptime Errors does instead, and why the wording is deliberate
RealUptime Errors registers release metadata the same way. An optional API call (POST /api/v1/errors/releases) takes the release string, a commit SHA, and a repo URL, whenever those facts are available. A CI or deploy script makes the call.
From there, the product does exactly two things with that data. Both are deliberately narrower than a suspect-commit feature:
- A per-release health rollup. An issue's detail page shows which release it was first seen in and which release it was last seen in. It also shows the event count for each release you have deployed since.
- A compare link. The link concatenates the previous release's commit SHA and the current one into a URL your own Git host already understands. One click opens GitHub or GitLab's own diff view for the range between the two releases.
The compare link is the honest version of "which commit caused this." RealUptime does not clone, fetch, or scan your repository, ever, and it does not claim a specific commit caused an issue. The UI copy says "first seen in <version>; view the diff range." The diff range is exactly the commits between two releases you deployed, shown on your own Git host where you can read them.
The judgment about which line in that diff is responsible stays with the person who wrote it. Only there does enough context exist to make the call correctly.
The result is a smaller feature than automated suspect-commit detection, on purpose. An algorithm confident about causation it cannot verify is a worse tool than one that hands you the right five-commit range and lets you look.
How do you set up release tracking?
Setting up release tracking takes five steps and about ten minutes of CI configuration. The version numbers below describe our own SDKs. The shape is close to identical across Sentry, Rollbar, and most other trackers, because the release string is a convention, not a proprietary format.
- Pick a release identifier your deploy pipeline already has. A short git SHA is the easiest. It is unique, it is already in your CI environment as a variable, and it needs no coordination with anything else. A semantic version works too if you cut one per deploy.
- Set it at SDK initialization, so every event from that process carries it. This is a single field in the client config, set once, from an environment variable your deploy already injects (
GIT_SHA,RELEASE, whatever your platform calls it). - Register the release when you deploy, not when you build. The distinction matters if your pipeline builds an artifact and then promotes it through environments. The health rollup should measure when code was actually live, and a build timestamp and a deploy timestamp can be hours or days apart.
- Add the commit SHA and repo URL if you want the diff link. This step is optional. Release tracking works with just the version string, and the compare link needs the two extra fields. GitHub documents the range view behind it as comparing two commits.
- Check the issue list after your next deploy. Anything genuinely new should now say so. Anything that stopped after the deploy should show a last-seen release that matches.
Release tracking turns "did the deploy do this" from a question someone answers by scrolling through two dashboards into one that the issue page answers on its own.
The mistake that quietly breaks release tracking
The most common way release tracking silently stops working is a mismatch between two strings. The release string set at SDK init drifts from the one your build tooling uses elsewhere. A frontend build tags its source maps with a short SHA, the SDK is initialized with a full 40-character SHA read from a different environment variable, and the two never match.
Nothing errors. Events still ingest. They carry a release string that does not correspond to any registered release, so the health rollup and the compare link quietly have nothing to show.
If a release's timeline looks empty even after real deploys, check the two strings. The one in the SDK config and the one in your registration call must be byte-for-byte identical, not just "close enough for a human to recognize."
If release tracking is the feature you care about, see how RealUptime Errors compares to Sentry on it and the rest of the feature set. Or start free with 10,000 events a month and try release tagging against your own deploy pipeline before paying for anything.