Can GitHub Detect Duplicate Issues Before They Pile Up?
Yes, as of a 2026 public preview: GitHub now flags likely duplicates while someone is filing a new issue, comparing the draft against open issues in that same repository and surfacing up to three matches before submission. It catches a real slice of the problem. It does not catch duplicates that live in a different repo, a different tracker, or a support ticket that never became a GitHub issue at all.
That scope limit is the whole story here, so let's be precise about it.
What the native feature actually does
GitHub's own changelog announcement covers the mechanism in one line, saying it flags "potential matches against existing issues in the repository as issue details are being populated." That's the extent of what the changelog post itself specifies. The operating details below come from a GitHub staff reply in the community discussion thread that followed the announcement, not from the changelog:
- It triggers once a draft issue's title reaches about 20 characters and the body reaches about 100, a threshold GitHub staff described as balancing match quality against showing suggestions before someone has already committed to submitting.
- Matching is semantic, not just keyword overlap, so "export hangs on large CSVs" can still surface "download times out over 50MB" as a candidate.
- Suggestions are non-blocking. The reporter sees up to three possible matches and can dismiss them and submit anyway.
- The comparison set is issues already open in that one repository. Nothing outside it.
That last point is the one people notice fast. The thread is mostly positive about the matching quality itself, with the loudest follow-up requests being for lower character thresholds and a manual re-check button for issues written all at once. Nobody in it reports the feature finding a duplicate across repos, because it isn't built to.
Where the repo boundary bites
Repo-scoped matching is fine for a single-repo project. It stops being fine the moment your product spans more than one:
- A monorepo split into services. The same billing bug gets filed against
apiby one user and againstwebby another, worded differently enough that even semantic matching inside each repo never sees the other report. - A public repo plus an internal one. Community bug reports land in the open-source repo; the same issue, escalated by a paying customer, gets filed by support into a private tracking repo. Native detection can't compare across that boundary at all.
- Anything that arrives as a ticket, not an issue. A user emails support, a teammate pastes the same complaint into Slack, and someone eventually opens a GitHub issue for it days later, phrased from memory rather than the original words. By the time it's an issue, the earlier reports of the same problem were never in GitHub to compare against.
None of this is a knock on the feature. It solves the problem it was built for, cutting the odds that two people filing into the same repo on the same day both create fresh issues for the same bug. It was never scoped to solve dedup across a whole product surface.
The gap people were already patching before this shipped
The repo-scoped gap predates the 2026 preview by years, which is why third-party bots exist for it. probot/duplicate-issues is a GitHub App built specifically to comment on new issues with a template linking likely duplicates, configurable per repo. It's a real, working pattern, and also a useful data point on how long this has been a known problem. The last commit to its actual codebase (the master branch) landed September 5, 2022, a Renovate config change, and nothing has been merged since. The only newer-dated activity on the repo is an automated Dependabot branch from September 2024 that bumps Express and was never merged, so it doesn't count as maintenance. Four years of silence on the tool built to patch this exact gap is the real measure of how long it's been sitting there unaddressed, well before GitHub's own tooling caught up to roughly the same job.
Bots like it, and GitHub's native version now, share the same ceiling: they compare text inside issues. Neither one knows that a "duplicate" is actually the same customer complaint that also came in as a Zendesk ticket last Tuesday and a Slack message from a teammate the Tuesday before that.
The same Postgres bug, filed in three places, seen by nobody
Marisol Ferreira maintains the ingest pipeline at Loomstack, a data-observability startup with three GitHub repos: loomstack/core, loomstack/connectors, and loomstack/dashboard. Here's what landed across three different systems in a single week, all describing the same row-drop bug:
| Where | Who | What was reported |
|---|---|---|
Issue #412, loomstack/connectors | Community user | Postgres connector drops rows when the source table has a JSONB column with nulls |
| Zendesk ticket #2290 | Paying customer | Missing about 4% of rows syncing from Postgres; support pointed them at JSONB fields, which they have |
| Slack, #customer-escalations | The account's CSM | Following up on the row-drop issue again, asking for an ETA |
GitHub's duplicate detection never sees the second two rows in that table, because neither one ever became a connectors issue. If a second community member later files their own JSONB report in the same repo, the native preview will probably catch that one. It has no way to connect issue #412 to the ticket or the Slack thread, so from GitHub's point of view there's one report, one requester, and no urgency signal. In reality there are three surfaces reporting the same bug, one of them a revenue account with a CSM already asking for a timeline. Marisol only found out about the overlap because she happened to be in both the Zendesk queue and the Slack channel that week.
issue filed·
report writtenWhere the DIY version stops working
You can extend repo-scoped detection by hand for a while:
- Turn on GitHub's native suggestions for every repo (no setup required, it's part of the issue-creation flow).
- Add a Probot-style duplicate bot on top for repos where you want an automatic comment rather than just an inline suggestion.
- Keep a habit, borrowed from larger triage playbooks, of running a scheduled sweep where someone manually cross-checks new issues against the support queue and recent Slack threads.
That third step is where it stops scaling. It works when one person can hold "everything reported this week" in their head across three or four sources. Past a few dozen reports a week spread over multiple repos and a support tool, the manual cross-check either falls to someone's memory of a Slack thread from ten days ago, or it stops happening, which is the same wall covered in more depth in our roundup of AI triage tools for engineering teams.
That's the point where we'd suggest looking at Modem. Modem connects to GitHub, Zendesk, Slack, and the rest of your support surfaces, and it doesn't need two similarly worded issues to land in the same repo before it recognizes them as the same problem. It reads the actual content of each report and clusters it with prior reports of the same underlying issue, regardless of which repo, tool, or channel it arrived through. The Postgres/JSONB example above becomes one topic with three linked sources and a running count, not three unconnected data points that a human has to notice overlap between. The GitHub integration syncs issue and PR metadata specifically so that dedup and follow-up work the same way whether a report started as an issue, a ticket, or a message. Full disclosure, Modem is the thing we sell here, and the honest counterpoint is that the native preview plus a Probot bot are both free and cover the single-repo case completely; if that's genuinely your whole surface, with no support queue or chat tool behind it, you don't need anything past what's already described above.
Turn the preview on, then add one habit
Turn on the native suggestions first. There's nothing to configure, it's already part of the issue-creation flow. If a repo is getting cross-team duplicates on its own, add a duplicate bot to it next. Neither one costs anything and both are worth doing regardless of what else you do.
Then add the one habit that covers the gap those two tools can't. Write down, in a single sentence, which non-GitHub source is most likely reporting the same bugs your repos are (support tickets, a Slack channel, whatever it actually is), and check it by hand the next time a report feels like it's been seen before. That habit catches most of the cross-surface duplicates until volume makes it worth automating instead.
