Does Linear Automatically Catch Duplicate Feature Requests?
No, not on its own. Linear will not look at a new issue, notice that nine other people already reported the same thing, and merge them for you. A person has to open the issue in Triage, recognize the repeat, and point it at the canonical one. Linear does merge attachments, comments, and any attached customer requests onto that canonical issue when you do this, and it cancels the duplicate cleanly. The mechanics are solid. The noticing is not automatic.
There's one partial exception, and it matters enough to explain properly: on Business and Enterprise plans, a feature called Triage Intelligence will proactively suggest that a new issue might be a duplicate of an existing one, based on semantic similarity. That's real detection, running on every incoming issue without anyone asking it to. But it stops at the suggestion. A person still has to look at the suggested relation and accept it before anything merges. If nobody looks at Triage that day, the suggestion sits there and the duplicate stays open as its own issue.
What actually happens when a duplicate lands in Triage
Every issue that comes in through an integration, or gets filed from outside the receiving team, lands in Triage first. According to Linear's Triage docs, a person working the queue has four things they can do with any issue sitting there:
- Accept it, which moves it to the team's default workflow state.
- Mark as duplicate, which prompts you to pick the existing issue it repeats, merges the two, and cancels the duplicate.
- Decline or snooze it, for issues that aren't actionable yet or aren't duplicates at all.
Marking something as duplicate is the action that matters here, and it's a deliberate choice, not a background process. You have to recognize that the issue in front of you is the same complaint as one already in the tracker, search for that issue, and select it. Linear then folds in whatever the duplicate was carrying, so a fifth bug report doesn't just vanish when it's marked as a repeat of the first.
That's the whole mechanism, and it's a good one for a person who's paying attention. The gap is entirely about attention: Triage doesn't flag "this looks like #1204" unless a human is the one doing the looking, with one exception.
Triage Intelligence: the closest Linear gets to automatic
Linear's Triage Intelligence feature is built specifically to close part of this gap. Per the docs, it analyzes incoming issues and "proactively surfaces suggested issue properties and relationships," including likely duplicates and related issues, based on the content of the new issue against what's already in the workspace. When it finds a match, a suggestion appears on the issue, and the person triaging can accept it, dismiss it, or open the referenced issue to check before deciding.
Two specifics matter here. First, it's gated to Business and Enterprise plans, so it isn't available to every Linear workspace by default. Second, even where it's on, it's a suggestion layer sitting on top of the same manual Triage flow described above. Some issue properties can be configured to auto-apply when suggested, but duplicate merging isn't one of the things that happens without a click. The system tells you where to look; you still decide.
“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 NotionRidgepoint Systems, six weeks into Triage Intelligence
Ridgepoint Systems builds uptime monitoring for API teams. Bug reports there come in three ways: a Slack Connect channel shared with customers, a support inbox, and the occasional GitHub issue on the public SDK repo. Zapier and Linear's own GitHub sync funnel all three into Linear as separate issues. At 40 people, Ridgepoint is still small enough that its engineering lead, Yusuf Demir, reads most of what lands in Triage himself, which is what turning on Triage Intelligence six weeks ago was supposed to help with.
Yusuf pulled up the queue on a Thursday partway into that six-week stretch:
Yusuf, in the team's triage channel: "Webhook retries silently drop after 3 attempts" showed up three times this week: once from Slack, once from a support ticket, once as a GitHub issue with a slightly different title. Triage Intelligence flagged the GitHub one as related to the first Slack issue, which was right. It never caught the support ticket at all, probably because the wording was completely different. The customer called it "webhooks stop working after a few tries," with no mention of retries. I only caught that one because I happened to read all three the same afternoon.
Nothing here is a bug in Linear. The AI matched what it could match on content similarity, and a human still closed the gap it left. The problem is that "a human happened to read all three the same afternoon" isn't a system, it's luck, and it breaks down the first week Yusuf is out sick or the queue triples during an incident.
When one triager can't keep up
The manual-plus-AI-suggestion setup works fine at Ridgepoint's current volume, where a handful of issues a week land in Triage and one person can hold most of the open backlog in his head. It stops working on a predictable schedule, not a random one:
- Volume climbs past what one triager reads end to end. Triage Intelligence only compares a new issue against existing Linear issues. It has no visibility into the Slack thread and the support ticket that haven't become Linear issues yet, so two of your three duplicates might already exist as separate issues by the time anything gets flagged.
- Wording drifts too far for semantic matching to catch. "Webhooks stop working" and "retries silently drop after 3 attempts" describe the same bug to a person and might not read as close enough to a similarity model trained on issue text alone.
- The count on the canonical issue understates real demand, because reports that got triaged as duplicates before Triage Intelligence existed, or that a tired triager missed, never got folded in. An issue with two linked duplicates might really have six people behind it.
Past that point, teams add a layer that catches the duplicate before it's three separate Linear issues to begin with, rather than trying to catch it better after the fact. That's the problem Modem is built around: it reads Slack, support tools, email, and call transcripts alongside GitHub, matches differently worded reports of the same bug or request into one counted topic, and then files a single Linear issue with every report and reporter already attached, before Triage ever sees three copies of the same problem. We build Modem, so weigh that against the fact that Linear's own Triage plus Triage Intelligence genuinely covers a smaller team's volume well; the tradeoff is explained in more depth in is Linear enough for managing customer feedback. The general shape of catching duplicates before they reach a tracker, GitHub included, is covered in how to triage GitHub issues at scale.
Bottom line
Linear does not automatically merge duplicate feature requests or bug reports. Triage requires a person to mark something as a duplicate and choose the issue it repeats. Triage Intelligence, on paid plans above the base tier, will suggest likely duplicates based on issue content, which is real detection work Linear does for you, but it still ends in a suggestion someone has to accept. If your reports mostly arrive as Linear issues already and one person can review Triage daily, that combination catches most of what matters. If reports arrive scattered across Slack, support, and GitHub before anyone files them, the duplicate work is happening upstream of anything Linear can see.
