Is a Sentry Regression the Same Bug a Customer Already Flagged?
Yes, technically, but that answer is doing less work than it sounds like. Sentry's issue states documentation defines Regressed plainly: "a resolved issue that's come up again," meaning a new event matched the same underlying issue after you'd marked it fixed. That match is real and automatic. What it does not mean is that the regression is the same complaint the customer filed, because Sentry's regression check has no idea a customer filed anything in the first place.
Those are two different questions wearing one label. The first is "did this exact grouped error recur after we resolved it," which Sentry answers for you, correctly, every time. The second is "is this the thing the account team pinged us about in March," which requires a link between the issue and a conversation that Sentry never stored, because Sentry doesn't track conversations. Confusing the two is how a regression gets reopened, refixed, and closed again without anyone ever telling the customer who'd been waiting on it.
What the Regressed label actually verifies
Resolving an issue in Sentry isn't a single action, it's a choice of baseline. The states and triage docs offer three release-scoped options: resolve in the next release ("use when the fix is ready but not deployed yet"), resolve in the current release ("use when the fix is already live"), or resolve in another existing release you pick by hand, typically for a hotfix on an older version. Whichever you choose sets the cursor Sentry checks going forward.
From there, the mechanism does exactly what the label implies. If the same issue's fingerprint produces a new event on a release past that cursor, status flips to Regressed automatically. That's a genuinely useful, narrow guarantee, Sentry is confirming grouping identity, not guessing at it. It's also the same fingerprint mechanism that decides whether two errors count as "the same issue" anywhere else in Sentry, a hash built from stack trace frames, or falling back to exception type and message when frames aren't available, as Sentry's grouping documentation describes it. Regression detection didn't invent a separate notion of sameness. It's reusing the one Sentry already had.
What it doesn't verify, and why that's the actual question
Nothing about that mechanism touches identity. Sentry's Activity tab does log a chronological history on the issue, assignments, regressions, escalations, and any comments a teammate chose to leave, but "chose to leave" is the operative phrase. If nobody wrote down which account flagged the original bug back when the issue first resolved, the regression six weeks later reopens with zero trace of who cared about it the first time. The user identifiers on individual events still work the same way they always have. Sentry's user context docs are clear that Sentry.setUser() is something your app calls, not something Sentry infers, so whether you can even see a user on the regressed events depends on instrumentation decisions made long before the regression happened.
So the gap is this: the Regressed label answers "is this the same grouped error," reliably, every time. It cannot answer "is this the account that already complained," because that answer lives in whatever support ticket, Slack thread, or call notes described the original report, none of which Sentry has ever seen.
The false negative nobody expects
There's a second failure mode that runs the opposite direction, and it's the one that actually costs people trust. Because regression detection depends on matching the same fingerprint, a bug can come back in a form a customer would recognize instantly while producing a stack trace Sentry doesn't recognize at all. Ship an adjacent code change, a wrapped call site, a refactored function name, a new library version that reshuffles frames, and the recurrence hashes differently. It doesn't regress the old issue. It opens a brand-new one, First Seen today, event count zero-and-climbing, with no Regressed label anywhere on it, even though it's the exact same customer hitting the exact same workflow failure they reported before.
That's worse than a missed label, it's an issue that looks brand new to everyone triaging it, including whoever would otherwise have remembered the original conversation. If your process is "check is:regressed for repeat bugs," this case walks straight past that filter.
Where the manual check stops scaling
For one regression and one customer relationship worth protecting, that lookup takes about ten minutes. Open the regressed issue, pull the affected user identifiers, check them against your account list, then go searching Slack or your ticketing system for whatever thread the original resolution was tied to. It's doable only as long as someone on your side still remembers the original conversation existed.
It stops being doable at volume. A team resolving forty issues a month can't rely on someone remembering which account cared about which fix six weeks later, and Sentry's own Activity log only helps if someone wrote the connection down while it was fresh. Multiply that by every issue that regresses, plus every "same bug, different fingerprint" case the regression label misses entirely, and the link between a bug and the person who reported it depends entirely on human memory holding up under interruption.
Taking that off human memory is the job Modem does. Modem's Sentry integration reads issues and their events the same way Sentry's own UI does, then matches the accounts behind them against what those same accounts have said in Slack, support tickets, or calls, whether the current event landed on a fresh Regressed label or on a brand-new issue with a shifted fingerprint. The question your account manager asks, is this the same customer again, becomes something answerable from the issue itself instead of a recalled Slack thread. Modem is the company writing this guide, so weigh the pitch against your own volume. If regressions are rare enough that someone always remembers the original thread, the manual check above is a reasonable place to stop.
For the mechanics behind why the same bug sometimes files as a different issue instead of a regression, see why Sentry splits one error into multiple issues. For turning a Sentry user identifier into an actual account name, see how to find out which customers hit a Sentry error.
Before you close the next regressed issue
Search is:regressed in your project, and for each result, pull the affected user or account identifiers off the new events before you touch anything else. Then check whether the account matches whoever was in the original thread, if you can still find it. If you can, write the outcome back into the issue's Activity log as a comment before closing it, so the next regression on this issue starts from a record instead of a memory. If you can't find the original thread at all, that's the actual answer to how long this has been working: only as long as someone stayed around to remember it.
