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 question is simple and the tracker's answer to it is usually missing, because most teams install an error tracker's SDK and stop there, without ever telling it what a "release" is. Without that one piece of setup, every issue looks the same age, every error looks like it has always been happening, and "did this start with the deploy" turns into someone manually cross-referencing timestamps against a deploy log in another tab.
This is a walkthrough of what release tracking actually does, honestly stated: what it can tell you for certain and what it can only suggest, using Sentry's own documented approach as the reference point, then how the same idea is implemented in RealUptime Errors.
What a release is, to an error tracker
A release is a string, nothing more: a git SHA, a semantic version, a build number, whatever your deploy pipeline already produces. The tracker's job is to attach that string to every event it receives while that version is live, and to every SDK call it makes, so the events form groups by version instead of one undifferentiated pile.
Once that attachment exists, three questions become answerable that were not before:
- 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 that spikes the moment a new version goes live is a different signal than one that has been constant for a month.
- 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 requires exactly one thing from you: send the release string with every event, which for most SDKs is one configuration line, and tell the tracker when a release deploys, which is one API call from CI.
Where this tips into a claim you should not make
Sentry's own documentation describes what it calls a "suspect commit": for each in-app frame in a stack trace, working top-down, it checks blame data to find the most recent commit that touched that file and line, and treats that as suspect if it is under a year old. That is a genuinely useful feature for narrowing down where to look. It is also, read carefully, a correlation: the last person to touch a line, not necessarily the person whose change is wrong. That 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 happens to touch 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 we do instead, and why the wording is deliberate
RealUptime Errors registers release metadata the same way: an optional API call (POST /api/v1/errors/releases) that a CI or deploy script hits with the release string, a commit SHA, and a repo URL, whenever those facts are available. From there, the product does exactly two things with it, deliberately narrower than a suspect-commit feature:
- A per-release health rollup, so an issue's detail page shows which release it was first seen in and which release it was last seen in, alongside the event count for each one you have deployed since.
- A compare link, built by concatenating the previous release's commit SHA and the current one into a URL your own Git host already understands, so one click opens GitHub or GitLab's own diff view for the range between the two releases.
That second part 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," and the diff range is exactly the commits between two releases you deployed, shown on your own Git host where you can actually read them. The judgment about which line in that diff is responsible stays with the person who wrote it, because that is the only place enough context exists to make the call correctly.
This is a smaller feature than automated suspect-commit detection, on purpose. An algorithm confident about causation it cannot actually verify is a worse tool than one that hands you the right five-commit range and lets you look.
Setting this up, concretely
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; the compare link needs the two extra fields.
- Check the issue list after your next deploy. Anything genuinely new should now say so, and anything that stopped after the deploy should show a last-seen release that matches.
Ten minutes of CI configuration 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 this
The most common way release tracking silently stops working: 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 just 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 that the string in the SDK config and the string in your registration call are byte-for-byte identical, not just "close enough for a human to recognize."
If you are evaluating error trackers and this is the feature you care about, see how RealUptime Errors compares to Sentry on release tracking and the rest of the feature set, or start free with 10,000 events a month to try release tagging against your own deploy pipeline before paying for anything.
Sources: Sentry, Releases & Health setup and Sentry, Suspect Commits, read September 21, 2026.