Prioritizing Sentry Issues by Customer Impact, Not Event Count

You can't. Sentry's issue stream sorts by Events, Users, Trends, First Seen, Last Seen, or its own Recommended field, and none of those six options know what an account pays you. A three-user issue and a three-hundred-user issue are ranked purely on the numbers Sentry has, which means a bug hitting three seats on your biggest account and a bug hitting three hundred free-trial signups can never be told apart by sorting alone. The trial-signup bug always wins the count, whether or not it's the one that matters.

Getting to "which paying accounts are hit" takes two things Sentry doesn't do for you: an identifier on each event that says which account it came from, and a lookup against Stripe or Salesforce that turns that identifier into a plan tier and a renewal date. Here's how to build that by hand, and the point where doing it by hand for every issue stops being realistic.

Sentry issue

one crash, a handful of users, on a paid account

Account cus_1042

the same account, on a paid plan, no connector between them

↓ both carry the key: email domain

one match, one pair

both point to the same paying account, with its plan and renewal date

key pasted by hand into the Sentry issue description

nothing writes back to the Stripe account automatically

What Sentry's ranking actually looks at

Sentry's own Issue Details page tracks a header with "total counts of how often it has been seen, and how many users it has affected," plus a graph you can toggle between event and user counts. That's the full picture. There's no field on the page for plan, MRR, or account tier, because Sentry has no concept of any of those things.

The issue stream's sort options confirm the same gap from a different angle: Recommended, Last Seen, First Seen, Trends, Events, and Users. Sentry also assigns issues an automatic Priority of High, Medium, or Low, but that score is built from "log level (for error issues) or actionability," and, if you're on a Business or Trial plan running a Python or JavaScript project, "error message, whether or not the error is handled, and historical actions taken on similar issues." A crash that fires as error level on your top account and a crash that fires as error level on a churned trial get the same Priority treatment either way.

Sentry's searchable issue properties don't include account, customer, or revenue fields either, so there's nothing to filter by out of the box. What you can do is attach your own: Sentry.setTag('account_id', org.id) on an event, documented as part of Sentry's tags and context system, becomes a real search field the moment it's wired up, so a search like account_id:<your-account-id> works exactly like Sentry's built-in filters. That's the fix, and it only covers events captured after you add the tag. Everything already in the stream still needs a manual join.

The manual join, step by step

1. Pull the affected identifiers off the issue. If Sentry.setUser() is wired up, the issue's tags show user.email values; if not, you're limited to whatever else got captured. Filter by user.email:* to see the distinct list.
2. Group by email domain. Two emails at the same domain are almost always the same account; this is the fast, rough version of the join and it's usually enough to act on.
3. Look the domain up in Stripe or Salesforce. Stripe's dashboard search matches on customer email, and Salesforce Account or Contact search by domain gets you the plan tier, MRR, and renewal date in the same minute.
4. Write the account name back into the Sentry issue as a comment, so the next person who opens it doesn't redo the lookup. Nothing does this automatically; Sentry has no field that would hold it even if something tried.
5. Add the tag going forward. setTag('account_id',...) next to setUser() means the next issue with this account doesn't need step 1 through 3 repeated.

That's a five-to-ten-minute task for one issue. The trouble starts when there are twenty open issues and no way to tell, without doing this for each one, which three actually touch a paying account.

Where the manual join stops working

The check above takes under ten minutes, but it only pays off on the issues someone actually opens, which means opening the low-count issue instead of skipping past it for the high-count one. That's the part that doesn't hold up as volume grows:

• Nobody checks every issue. A team triaging a dozen new issues a week isn't running a Stripe search on each one before deciding what to work on next; the low-count issues get deprioritized by default, silently, and some of them are hitting your largest accounts.
• The account tag only covers what gets instrumented. setTag('account_id',...) has to be added service by service, and it only applies to events captured after the code ships. Historical issues, and any code path someone forgot to tag, still need the manual lookup.
• Revenue data and error data live in genuinely separate systems. Stripe knows MRR, Salesforce knows renewal dates and account notes, and Sentry knows stack traces. Nothing keeps those three in sync with each other; a renewal date changing in Salesforce doesn't touch anything in Sentry, so a renewal coming up in days, visible only in a Salesforce note, is exactly the kind of urgency that's easy to miss on a day nobody happens to check.

Past a handful of issues a week, or once a team has more than a couple of Enterprise accounts worth checking for, this is the point where the domain-to-Stripe lookup needs to happen on every issue by default, instead of only on the ones someone remembers to check.

Setting that default is what Modem does. Modem's Sentry integration lets an agent search issues, read stack traces and user feedback, and, with your approval, resolve, assign, or reprioritize them; its prioritized view groups issues by what people are actually asking for and ties each one to the accounts that raised it, so the domain lookup in step 3 above is already done. Modem's Stripe integration matches Stripe customers to those same accounts, so you can ask the agent which open issues touch a given plan tier or MRR band instead of running the Stripe search yourself. It's still a question you ask and a change you approve, not an automatic re-sort of the Sentry issue stream by revenue. We build Modem, so weigh that against doing the join yourself with the steps above; for the identity side of this same problem, how to find out which customers hit a Sentry error covers getting from a user ID to an account in more depth, and how to tell if the customer emailing support is your biggest Stripe account walks through the same revenue check from the support side.

Check the low-count issues before you trust the sort

Before triaging the next batch of new issues, don't sort by Events or Users first. Sort by First Seen, open the ones with fewer than ten affected users, and run the domain-to-Stripe check on each. It's the low-count issues that hide the expensive ones, and they're exactly the ones a count-based sort pushes to the bottom.