Is an Ignored Sentry Issue Still Affecting Customers?
Marking a Sentry issue Ignored, or Resolved, doesn't mean it stops happening. It means Sentry stops telling you about it, under one specific condition, and that condition is almost always about event volume rather than about who is hitting it. An issue you've archived (Sentry calls this action Archive today; older discussions and some tooling still call it Ignore) comes back to your attention only if its events spike sharply over a short window, a state Sentry labels Escalating. A Resolved issue reopens only if the exact same error recurs in a release newer than the one you fixed it in, a state Sentry labels Regressed. Neither check knows anything about the accounts behind the errors.
Sentry's own automation only tells you when a problem gets a lot worse, fast. That's the honest answer to whether an ignored issue is still hurting customers. It says nothing if the problem just keeps happening at the same low rate it was at when you archived it, and it has no concept of whether that steady rate is spread across a hundred free-tier signups or concentrated on the three accounts up for renewal. Getting a real answer means reading Sentry's states correctly, then checking something Sentry doesn't track at all.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notionthe support leadWhat archiving actually watches for
Sentry's issue states documentation describes archiving as moving an issue "out of the issue stream" and pausing alerts on it "until" a condition is met. By default, that condition is "until escalating." Sentry keeps recording every event against the issue, and if the event count rises significantly compared to its recent baseline, the issue jumps back to the top of your stream with an Escalating label. That's a real, useful mechanism, and it's also the only one of the four archive options that pays attention to the issue at all after you archive it.
The other three options are flat thresholds, not volume watches. Archive for a set period of time, until it happens a set number of times more, or until a set number of new users hit it. There's also a fourth option, Forever, and it works differently again. The docs state plainly that an issue archived forever "will never be labeled as escalating even if it meets escalating conditions." Events keep recording. Nothing brings it back. If your team's habit is to archive forever because a bug "isn't worth the noise," you've turned off the one mechanism that would have told you if that judgment stopped being true.
Escalation reads volume, not accounts
Even the default "until escalating" behavior is just a statistical trigger. It watches one number, events per unit time, relative to what's typical for that issue. It has no field for account tier, no join against your billing system, no idea that the fifteen events an hour it's ignoring belong to your two largest logos rather than fifteen different trial signups. A bug that fires reliably every time a specific customer runs a specific workflow generates a flat, boring line on Sentry's event graph. Flat lines don't escalate. That customer can hit the same error every day for months without the issue ever leaving Archived.
The issue alert configuration docs confirm alerting rules see the world the same way. One of the standard alert triggers fires "when an issue escalates or moves from resolved back to unresolved," the same volume-and-regression logic, just routed to Slack or email instead of the issue stream. If you built your Slack alerts around escalation and regression, as most teams eventually do, you've built them on the same blind spot.
The Resolved side has its own quiet gap
Resolving an issue is a bet that a specific fix, tied to a specific release, actually worked. Sentry's docs describe the check on that bet in one plain sentence: "If the same issue comes back in a newer release than the one you resolved it in, its status will automatically change to Regressed." That's a precise, narrow condition. It says nothing about an issue that keeps firing on an older release still running in production, whether because a customer is on a pinned version, hasn't upgraded, or is running self-hosted infrastructure you don't fully control. Those events keep landing on the resolved issue without ever triggering a regression, because regression detection is checking the release number, not asking whether the underlying bug is still live somewhere.
A promo-code bug that never spiked
InvalidDiscountStackError first showed up in the Sentry project for Portside Outfitters, an outdoor-gear retailer whose checkout runs through a third-party promo engine, four months ago. It fired 60 times over two days when a customer applied two promo codes in sequence during a flash sale, then dropped off once the sale ended. Naledi Botha, the staff engineer who triaged it, judged stacked codes a rare edge case and archived the issue forever rather than pull apart the promo engine's validation order mid-sprint.
The bug never actually went away. It resurfaces every time Portside runs a member-appreciation sale, because the loyalty program automatically applies one code and lets members stack a second on top, and it hits the same handful of high-spend repeat customers each time, at roughly the same low volume as the original spike, four sales running.
Nobody caught it until Cole Danby, a support lead, flagged a pattern in the engineering Slack channel this week: another round of "my discount didn't apply, had to email you to get it fixed" tickets from repeat buyers, and it felt familiar enough to ask if the team had ever looked into it. Naledi pulled up the old issue and found it was still recording events, sixty-something more since June, mostly the same email addresses each time.
Sentry never surfaced any of this on its own, because archiving forever turns off escalation entirely, and even without that setting, a steady handful of events per sale was never going to read as a spike on the event graph. It took a support lead noticing a pattern in ticket language, four sales cycles after the team considered the bug handled, to catch what Sentry's own event data had been recording the whole time.
Where the manual check stops working
Once you know to look, checking an archived issue yourself isn't complicated. Search is:archived, sort by last-seen, and skim the event graph for anything still recording. Cross-reference the affected user.email or user.id values against your own customer list to see whether the same handful of accounts show up every time. That's real work, but it's doable for one issue.
It stops being doable as the archive pile grows. Every issue anyone has ever archived forever, or archived on a threshold, is a candidate for this same check, and Sentry gives you no ranking of which archived issues are worth spending that ten minutes on versus which really did stay dead. There's also no persistent link between "these email addresses keep hitting this issue" and what those same accounts are saying in support tickets or renewal calls, so even after you spot the pattern, connecting it to "this is costing us a renewal" is a second manual lookup, done from scratch, the next time someone asks.
That's the gap Modem works on. Modem's Sentry integration reads archived and resolved issues the same way it reads new ones, resolves the user identifiers on their events to the people and accounts behind them, and surfaces when an archived issue is still recording events tied to real customers, next to whatever those same accounts have said in Slack, support, or a call. The question Cole asked, in the example above, becomes something Modem can answer from the issue itself instead of a support lead noticing the tickets felt familiar. For the mechanics of resolving a Sentry user identifier to an actual account in the first place, see how to find out which customers hit a Sentry error; the underlying idea of keeping errors linked to the accounts and conversations behind them is covered in what a customer context graph is. Full disclosure: Modem is what we build. If your archive pile is small enough that the manual search above covers it in fifteen minutes, that's a perfectly reasonable place to stop.
Try this on your own is:archived list
Search your project for is:archived, sort by events, and open the ones still recording. For any that are, pull a handful of the affected user.email values and check them against your customer list by hand. If any of them belong to accounts you'd recognize by name, that's your answer, and it's worth writing the account list into the issue as a comment before you close the tab, so the next person who opens it isn't starting from zero.
