How to see which customers are affected by a Jira bug
Jira doesn't keep a number for this. There's no field on an issue that says "6 customers affected" and updates itself as more reports come in. The closest native answer is to open the issue's linked items and count how many are marked as duplicates, then check the Votes count, then hope nobody reported the same bug through a support ticket or a Slack thread that never got linked at all.
That's a real answer, just not a complete one. Jira tracks three separate signals that each carry part of the picture, and none of them was built to answer "how many customers does this affect" on its own. Here's what each one covers, where a practitioner asking almost this exact question on Atlassian's own community landed, and what to do about the gap.
What Jira actually tracks
Three mechanisms get you partway there, and each one misses something different.
Linked issues, specifically duplicates. Jira ships "duplicates" and "is duplicated by" as native link types, alongside blocks, clones, relates to, and a handful of others. If your team has a habit of linking every repeat report back to the original instead of just closing it, the linked-issues panel on the original bug becomes a rough count. However many issues say "is duplicated by" is roughly how many separate times someone hit it. It only works if the habit holds, and it only counts reports that became separate Jira issues in the first place.
Votes. Anyone with access to the project can click Vote on an issue, and the vote count shows on the issue view. It's the nearest thing Jira has to a built-in tally, but it has a real limit. One person gets one vote, so it counts distinct voters, not distinct customers, and says nothing about which account each voter belongs to. A single power user from your biggest customer and five free-tier users from five different companies both show up as five votes.
Nothing else, natively. A practitioner asked this almost word for word on the Atlassian Community forums. They wanted to prioritize bugs by how often they were reported, not just by severity, and were looking for something that increments automatically each time the bug gets reproduced. The thread confirms there's no built-in hit counter. A related feature request, JRASERVER-21303, asked Atlassian for automatic bug-count reporting by week; Atlassian marked it fixed only by folding it into a follow-up ticket, which it then closed as won't-fix in 2019 without shipping either one. The workarounds people land on are a custom numeric field seeded at 1 and bumped manually or by an automation rule each time someone confirms a repeat, or just leaning on the duplicate-linking habit above and counting the links by hand.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhy the manual habit breaks down
The fix most teams reach for is discipline. Search before filing, always link duplicates, and ask support and CS to flag repeat reports in the ticket instead of answering and moving on. That works as long as everyone who might hit the bug funnels it through the same intake path, and as long as whoever answers a customer directly remembers to go check Jira for a matching ticket before replying.
Both of those assumptions get shakier as the team grows. Support agents, CSMs, and account execs each have their own channel for hearing about problems, and searching Jira before every reply isn't how any of them are trained to work. The repeat report that does get linked usually gets there because a triager happened to search the right two-word phrase. Most repeat reports arrive worded just differently enough that a keyword search misses them, which means the duplicate-linking habit tends to catch the cases where the phrasing lines up and miss the ones where it doesn't, systematically undercounting exactly the reports that are hardest to search for.
This is a smaller-scale version of the same gap covered in why customer feedback tools are hard to keep prioritized. Ranking a backlog only works if the thing feeding the rank actually catches every report, and a search-then-link habit run by hand doesn't scale past a handful of channels.
What closes the gap
The reason this is hard in Jira is that "who's affected" isn't a Jira concept. Jira issues have a Reporter, one person, one time. They don't have a running list of every account that hit the same underlying problem across support, Slack, and email. That's a related but different gap from tracking who originally asked for a Jira epic or story: that guide is about a single requester's identity surviving edits, while this one is about counting every affected account without hand-searching for phrasing matches.
Counting them without the hand-search is what we built Modem for. Modem's Jira integration reads the projects you connect, and separately reads Slack, support tickets, and calls, matching different phrasings of the same problem to one topic instead of relying on a keyword search catching the overlap. Every company and person that reported it stays attached to that topic, so a bug carries its real count rather than only the reports that happened to get linked or voted. Ask an agent who is affected by a given issue key and it answers from that topic instead of from whatever a triager managed to search and link by hand. One more thing worth flagging: Modem is what we sell, so this section isn't neutral. Judge it by the specific claim, not the source, checking whether search-and-link actually catches every channel your team fields reports through before deciding you need something more.
None of this argues against duplicates and votes on their own. A two-person support team funneling every report through the same Jira project doesn't need anything more, and setting up a custom hit-count field takes an afternoon. What breaks the setup isn't volume, it's channel count: the moment support, CS, and sales are each fielding reports in their own tool without a shared habit of checking Jira first, search-and-link stops catching enough of them to trust the number it produces.
Where to begin
Pick one open bug you suspect is under-reported, and manually check three places: Jira's linked issues and votes, a Zendesk or Intercom search for the same symptom in different words, and your team's support Slack channel for the same window of time. Whatever gap shows up between "what Jira says" and "what actually turns up" is roughly the size of the problem this guide describes, and it's usually bigger than people expect on the first try.