Sort GitHub issues by customer value

Yes, but not the way most teams look for it. GitHub's own search supports sort:reactions-desc, which ranks issues by total reaction count across every emoji, and sort:reactions-+1-desc for thumbs up specifically, documented in GitHub's search qualifiers. Type either into the filter bar on your Issues tab and the list re-sorts. You don't need a script for that part, though it still won't tell you which reactor is worth caring about.

What GitHub can't tell you is who did the reacting. A thumbs up from a solo hobbyist counts exactly the same as a thumbs up from the account paying you six figures a year, because the reaction API returns a username and an emoji, nothing about which company that username works for or what they pay. Sorting by reaction count gets you "how many people clicked," which isn't the same question as "how much does this matter."

“we need SSO before rollout”

“any update on single sign-on?”

“SSO came up twice on this call”

↓ classified + deduped into

SSO requests

8 accounts asking · quotes kept

files

Linear issue, quotes attached

writes

insight report in Notion

answersyour agents

GitHub hands you a reaction count; the ranking that matters is how many distinct paying accounts sit behind it, which only shows up once each reactor is tied back to a company.

Step 1: use the sort GitHub already has

Before building anything, rule out the free option. The Issues tab's own Sort dropdown already has an entry for "The most added reaction on issues or pull requests," which is the same combined-reaction ranking you get from typing is:open sort:reactions-desc into the search bar. If you want one specific emoji instead of the combined count, that part is search-box only: sort:reactions-+1-desc for thumbs up, or sort:reactions-heart-desc for hearts, per the same qualifiers page. If your backlog is small enough that "most reacted" is a fine proxy for "most wanted," stop here.

Step 2: pull the actual reactor list

Reaction counts hide the names behind them. GitHub's API exposes them directly:

gh api repos/OWNER/REPO/issues/NUMBER/reactions --jq '.[].user.login'

That returns every GitHub username who reacted, which is the raw material for the question a count can't answer: are these forty reactions forty different companies, or four companies whose engineers all reacted from personal and work accounts?

Step 3: match reactors to the accounts you actually care about

This is the part with no native GitHub feature, because GitHub has no concept of your customer list. Export the reactor usernames from step 2 and cross-reference them against whatever already maps people to companies on your side: a CRM, a support tool's contact list, or a plain spreadsheet if that's what you've got. GitHub usernames rarely match email addresses cleanly, so this usually means checking each reactor's public profile for a company or matching them against known engineers at accounts you track.

For a backlog with a handful of open issues a week, this is tedious but doable by hand once a week.

What breaks first as the backlog grows

The approach above breaks down on ordinary schedules, not edge cases:

Reactor-to-account matching doesn't scale past a handful of issues a week. Pulling usernames and checking each one against a customer list is a real task, and it's the first thing that gets skipped when the backlog gets busy, which is exactly when it matters most.
GitHub usernames aren't stable identifiers for a person. The same engineer might react from a work GitHub account on one issue and a personal one on another, and nothing links the two unless you already know to look.
The context lives in one place and the reaction lives in another. Knowing "this account is on our top-tier plan and had a support escalation last month" requires checking a different tool for every reactor, every time.

A system that already knows who your customers are becomes cheaper than the habit at that point, with one limit worth stating up front: Modem connects to your GitHub repos alongside Slack, support, and email, and reads issue and PR content, not the reaction API, so it can't re-score the emoji counts from steps 1 and 2 for you. What it does instead is turn a GitHub issue into a tracked topic the same way a Slack thread or a support ticket becomes one, counted by the people who filed the issue and left comments rather than the people who clicked a reaction. Because Modem already holds the people and companies behind every channel it watches, that topic shows how many distinct customers and companies are actually behind a request, and a request that also showed up in a support ticket or a sales call gets counted as the same topic instead of a separate one. On a backlog where most real signal shows up as a comment or a linked ticket rather than a lone reaction, that covers more ground than reaction weighting alone would. On a backlog where reactions are genuinely the dominant signal, the manual reactor check from steps 2 and 3 stays the way to read it; Modem doesn't replace that specific check today. We build Modem, which makes us a biased source on this recommendation; the general shape of this problem, sorting the customer-facing slice of a tracker instead of the whole engineering backlog, is covered in more depth in how to triage GitHub issues at scale, and the wider set of tools that weight feedback by revenue instead of headcount is compared in best tools to prioritize customer feedback by revenue.

Start with your five most-reacted issues

Pick your five most-reacted open issues, pull the reactor list on each with the gh api command above, and check those usernames against your customer list by hand. This is the piece that stays manual even after you bring in a tool like Modem, since none of that tooling reads the reaction API either; what a tool changes is how much of the rest of your backlog needs the same treatment. You'll know within the hour whether your current top-of-backlog is actually your top priority, or just your most-clicked.