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 NotionTracing one bug across accounts
Voltway Systems builds the wireless card readers and back-office dashboard that mid-size retail chains use to run in-store checkout. In early September, one of Voltway's own support engineers files JIRA-1140: a customer's dashboard shows 0% battery for any card reader that's been charging for more than four hours, because a rounding bug wraps the displayed value back to zero. The reporting customer is Kestrel Logistics, and their name appears once, in the ticket description.
The engineer who filed it votes on the ticket out of habit, and ten days later a teammate fields a near-identical complaint from an unrelated Voltway account, doesn't recognize the wording as a match, and adds a second vote instead of writing up a new ticket. Both votes come from Voltway's own support team, not from any of the customers actually hitting the bug.
Two weeks after the original filing, a customer success manager forwards a Slack Connect message from Marchetti Foods describing the identical symptom, in different words: "our reader's been on the dock for hours and it's still showing 0%, is that expected?" Nobody connects it to JIRA-1140, because nobody searched for "0%" before answering; a new ticket doesn't get filed at all, and the CSM just replies that she'll check.
A third case reaches Dana Ferreira, who owns the bug backlog for Voltway's platform team, directly. An account exec at Vantage Rail loops Dana into an email thread because the bug is holding up a renewal conversation. This time someone does file a Jira ticket, JIRA-1158, and a sharp-eyed triager marks it "duplicates JIRA-1140." That's the only one of the three customer reports that shows up if Dana opens JIRA-1140 and checks linked issues.
When sprint planning comes around, Dana pulls up JIRA-1140 to decide if it's worth bumping ahead of a scheduled feature. Linked issues shows one duplicate. Votes shows two, both from Voltway's own support team. Neither number is wrong, exactly, but the true count is three companies, two of which never touched a field Dana would think to check, and one of which is mid-renewal.
Why 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 Vantage Rail case in the example above only got linked because the 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.
This is the layer Modem is built 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 like JIRA-1140 carries its real count, three companies, not the two that happened to get linked or voted. Ask an agent "who's affected by JIRA-1140" 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.
