How to Tell How Many Customers Are Actually Blocked by One GitHub Issue
Three comments on a GitHub issue could mean three customers. They could also mean one customer replying twice plus a maintainer, or one installer's account manager commenting under two different GitHub handles because nobody realized they were the same person. GitHub's comment count answers "how many replies did this thread get," and that is a different question from "how many customers are blocked," even before you consider that a fourth and fifth customer might have reported the exact same problem in a Zendesk ticket or a sales call that never touched GitHub at all.
Getting the real number takes two separate checks. First, read what the issue itself actually tells you, since GitHub has more signal than a raw comment count and most teams don't use it. Second, go find the copies of the same complaint sitting in the tools GitHub can't see, because for most companies the issue tracker is where engineers talk to each other, not where every affected customer shows up.
What the comment count is actually counting
GitHub's issue list can be sorted by "most commented" and by "most added reaction," and search supports both a comments: and a reactions: qualifier with greater-than, less-than, and range operators, so reactions:>10 or comments:>5 is:open both work as real filters (GitHub's search qualifier docs). That is genuinely useful for triage, since it separates the issue with one comment from a confused user asking for help from the issue with forty thumbs-up and a two-year-old open date.
What neither number does is dedupe. A comment count includes every reply from the same person, so an issue where one installer posted three follow-ups over two weeks reads identically, on the count alone, to an issue where three different customers each posted once. A reaction count is a total, not a roster, so "14 reactions" could be fourteen separate companies or one enterprise account's whole engineering team piling on from their own GitHub org. Neither number carries a company name, a plan tier, or a link to whatever that same customer already said in a support ticket. GitHub knows about the accounts that touched the issue on GitHub. It has no way to know about the ones who didn't.
Checking it by hand
Below a certain volume, a manual cross-check is a reasonable process, not a stopgap. The version that works:
- Search your support tool for the issue's own symptom words, not just the customer's account name, since the same bug gets described differently by every reporter.
- Search Slack for the account name plus a keyword, if support and sales share a workspace with customer channels, before assuming a Slack mention would have already surfaced.
- Check recent call notes or a transcript tool for accounts due for renewal or expansion, since a customer on a call is often describing the same blocker without ever filing anything.
- Paste what you find both directions, the ticket number as a GitHub comment and the issue link as an internal note on the ticket, so the next person doesn't redo the same search from zero.
Without it, every new person who opens the issue starts the cross-check over, and the answer to "how many customers" quietly resets to "however many commented on GitHub" until someone does the search again.
Where the manual version stops working
Three things break this down predictably as issue volume grows:
- Keyword search misses paraphrase. "Stale reading" and "dashboard's showing yesterday's numbers" describe the same bug and share almost no words, so a search for one won't surface the other unless the person searching already suspects a connection.
- The check depends on someone remembering to run it. A mention on a sales call only gets counted if whoever triages the issue happened to be on that call. Anyone working the same issue without that memory reports the comment count and stops there, and nobody catches the gap until a renewal is already at risk.
- It doesn't scale past a handful of open issues a week. Cross-checking one issue against Zendesk, Slack, and Gong by hand takes fifteen to twenty minutes done properly. A team with thirty open customer-facing issues doesn't have ten hours a week to spend confirming headcounts before every planning call.
Something has to read the other systems automatically instead of relying on a person to remember to check. Modem's GitHub integration does that by capturing issues as feedback alongside Slack, Zendesk, and Gong, then grouping differently worded reports of the same problem into one topic with every affected person attached, regardless of which tool they used to report it. A bug reported in all three places would show up as one topic with every affected person on it, whether they reported it through Zendesk, Gong, or GitHub, instead of an issue whose comment count undercounts the real number. Modem is what we build, so treat that last paragraph as coming from an interested party, not a neutral one. If your team's customer-facing bugs land almost entirely as GitHub issues, with support and sales rarely hearing about the same problem through a separate channel, the manual check above is probably enough on its own, and the only thing missing is the habit of actually running it every time.
The same undercounting shows up on other trackers. If your team runs on Linear instead of raw GitHub issues, see how to see every customer blocked by a single Linear issue for the version of this gap that shows up in Linear's own Customer Requests panel. And if a chunk of your reports arrive on sales calls rather than in writing, how to keep the customer account attached to a feature request after it leaves Gong covers the specific failure mode where a call mention never becomes a counted request at all.
Before the next planning call
Before you answer "how many customers does this affect" off an issue's comment count, run one search covering the issue's key symptom words against your support tool and, if calls are part of how customers reach you, recent call notes for any account due for renewal soon. That kind of gap usually surfaces because someone happened to remember a call, not because the process caught it. The habit that actually holds up over time is smaller than it sounds. Note the search terms you tried directly on the issue, even when the search comes up empty, so the next person who opens it inherits a starting point instead of a blank slate.