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.
The webhook issue at Arclight Solar
Arclight Solar sells monitoring dashboards to solar installers, software that reads live inverter output and flags panels underperforming their expected curve. When an installer filed an issue on Arclight's public API repo, "Inverter telemetry webhook fires with stale readings after firmware v4.2," three weeks after a firmware update shipped, it landed in the queue Delphine Beckett checks as the person running support there. Two more comments landed over the following ten days, one from a different installer confirming the same symptom, one from an Arclight engineer asking for a sample payload.
Before a release-planning call, Arclight's VP of engineering asked the question that comes up on every one of these calls:
VP of Engineering: Is this a hotfix-now bug or a next-release bug? How many customers does it actually affect?
Delphine's first answer, going strictly by the issue, counted two people, the original reporter and the one who confirmed it. She checked Zendesk for the same symptom before answering for real, searching "stale reading" and "inverter webhook," and found two more tickets from installers who had never opened GitHub at all, one of them filed the same week as the original issue. She also remembered a Gong call from the week before, an enterprise installer's operations lead mentioning "the dashboard's been showing yesterday's numbers since the update" on a renewal check-in that had nothing to do with support.
Delphine, in the planning doc: It's five, not two, and one of them is the account from Tuesday's renewal call. Two came through GitHub, two through Zendesk, and one only exists in a Gong transcript. None of the Zendesk tickets or the call are linked to the issue anywhere.
Nothing on the GitHub issue was wrong. Two people had commented. But "two comments" and "five customers blocked" were different numbers, and the gap was entirely in systems the issue itself has no way to read.
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. Delphine caught the Gong mention because she happened to be on that call. A different engineer triaging the same issue without that memory reports two customers, not five, 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.
That's the point where teams add something that reads 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. Arclight's webhook issue would show up as one topic with five people on it and two dates from Zendesk, one from Gong, and two from GitHub, instead of a two-comment issue that undercounts by more than half. 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. Delphine's two-versus-five gap surfaced 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.
