How to Know How Many Different Customers Are Blocked by One GitLab Issue
Read the Participants list in the issue's sidebar, not the comment count. GitLab defines a participant as anyone who commented, added an emoji reaction, or was mentioned on the issue, so it already catches the quiet "+1" reaction that a comment count misses. What it won't do is tell you whether two names on that list work for the same company, or whether a third company hit the identical bug and reported it somewhere GitLab never sees.
That second gap is the one that actually costs you. A five-comment issue with three participants might be one customer's engineer following up twice plus a colleague, which is one account, or three different companies, which is three. GitLab's own model has no field for "customer account," so the sidebar gives you people, and turning people into companies is a step you have to do by hand, every time, on every issue you're trying to size up before a planning call.
Who GitLab counts as a participant, and who it misses
GitLab's participants documentation is specific about who lands on that list: "Participants are users who interacted with work items and merge requests. They include authors, assignees, reviewers (for merge requests), and users who commented, added emoji reactions, or were mentioned in comments or descriptions." That's wider than a comment count in a useful way. Someone who never typed a word but dropped a 👍 on the issue shows up as a participant, which is real signal that a second person cares about the fix, not just noise from the original reporter typing more.
It's also wider in a way that works against you. The list includes your own team. An engineer who left a clarifying question, a teammate who got @-mentioned to review, and the assignee are all participants too, sitting in the same list as the customers who are actually blocked. Read the count on its own and you're mixing internal headcount into a number that's supposed to answer "how many customers." The list has to be read name by name, not counted.
Turning names into companies
Once you have the participant list, the actual work starts:
- Check the account behind each username. If commenters are logged-in GitLab.com or self-managed accounts, their profile usually carries an email domain or a company name in the bio. Two different usernames with the same email domain are one customer, not two.
- Read every comment for who's talking, not just what they're saying. A quiet "any update?" from the original reporter three weeks later is the same customer following up. A comment with a new symptom, a different environment, or a different account name attached is a second customer, even if the words are almost identical to the first.
- Don't skip reactors. A 👍 with no comment is still a participant per GitLab's own definition, and on a well-known account that reaction alone is worth chasing down, not filing away as unread noise.
- Treat Service Desk issues differently. If the issue came in through Service Desk, GitLab tracks people without GitLab accounts as external participants by email address, up to ten per issue, added automatically from the sender and optionally from anyone CC'd. That list is closer to a real customer roster than the GitLab-account participant list is, since it's keyed on email rather than on whoever happened to have a login.
None of this is hard. It's just manual, and it only covers people who touched this specific issue in this specific project.
Where the manual read runs out
This works fine at low volume, a handful of customer-filed issues a month. It stops holding up for reasons that show up predictably as that volume grows:
- Profile-checking every participant takes real time, and it's the first step people skip when they're behind, which is exactly when the miscount matters most.
- Searching your support tool depends on guessing the right words. The terms you reach for are the ones written on the GitLab issue. A ticket describing the same bug in the customer's own vocabulary would not have surfaced.
- The resolved count doesn't travel with the issue. A comment linking one Zendesk ticket sits on the issue, but the actual answer, how many separate customers are blocked, only exists in a planning thread. The next engineer who opens the issue in three months, chasing a regression, sees a ticket number with no context and still has to redo the cross-check from zero.
GitLab has acknowledged a version of this gap in its own tracker. Issue 296668, "Share an Issue/Epic To Multiple Projects or Groups," is still open years after filing, describing exactly the shape of the problem: GitLab's model keeps a request bounded to the container it started in, with no built-in way to see the same ask surfacing somewhere else. That issue is about one work item spanning multiple GitLab projects, not about a support ticket outside GitLab entirely, but it's the same underlying limit at a smaller scope, one where GitLab correlates activity inside a single container and stops looking the moment the trail leaves it.
Checking profiles by hand and guessing search terms holds up only as long as one person can keep doing it on every issue that needs a real count. Modem's GitLab integration watches the projects you connect for issue and comment activity, resolves each commenter and reactor to the company behind them instead of leaving that as a profile you check by hand, and correlates the same complaint against support tickets, Slack, and call transcripts automatically. A bug reported by two accounts on the issue and by a third in a support ticket would show up as one topic with every account that reported it attached, sourced from GitLab and Zendesk both, instead of a participant list that undercounts until someone happens to search for it. Modem is the product we build here, so read that description with the same skepticism you'd bring to any vendor explaining its own tool, and weigh it against the alternatives lined up in the best tools to turn customer feedback into GitLab issues. Below a few dozen customer-facing issues a month, checking by hand still holds up, provided someone actually runs it.
The same undercounting happens the other direction too, when GitLab can't tell which issues came from a customer at all. See how to tell which GitLab issues came from a real customer vs. an internal idea for that half of the gap, and what a customer context graph is for the shape of what changes once identity survives across tools instead of resetting at each one.
Before the next planning call
Before answering "how many customers" off a GitLab issue's comment count, open the Participants sidebar and check the account or email behind every name on it, reactors included, then run one search of your support tool for the issue's key symptom words. An undercount like that only closes because someone checks a profile and runs a search, not because GitLab surfaces either one. Write the resolved count directly on the issue, even the search terms that came up empty, so the next person who opens it in three months inherits an answer instead of starting over at whatever the participant count happens to say.
