How to route Discord bug reports into Linear without losing the reporter
Linear has an official Discord integration, and it will create an issue from a Discord message. It will not, on its own, keep track of which Discord user reported the bug. The /linear issue command requires the person typing it to have a Linear account already linked to their Discord account, which most of your community members don't have. The issue it creates carries a title, a team, and optional fields like assignee and project, but nothing that records who originally posted the report if that person isn't the one running the command.
Routing the bug report into Linear is the easy half. Keeping the reporter attached is a second step you have to build yourself, either as a habit a human follows every time or as a small bot that does it automatically. The rest of this walks through what the integration covers on its own, a DIY fix, and what fully closes the gap.
Two account links, then a command that drops the reporter
Per Linear's own Discord docs, setup has two layers. A workspace admin turns the integration on for the server. Then, separately, "every Linear user must individually link their account in order to use the Linear integration in Discord." Each teammate connects their own Discord identity to their own Linear seat under Settings > Integrations.
Once that's done, a linked user can type /linear issue in any channel and fill in a title and a team, plus optional fields for description, status, assignee, and project. That's the whole surface. There's no message context-menu action ("right-click → create issue"), and the docs don't describe the resulting issue carrying any reference back to the Discord channel, message, or author. Practically, this means:
- A community member without a Linear seat can't file the issue themselves. Someone on the team has to do it for them.
- Whoever runs the command is the one Linear records as the issue's creator, not the person who reported the bug.
- Nothing about the integration ties the report back to a specific Discord identity beyond whatever a human decides to type into the description by hand.
- Linear does let someone attach a Discord message to an existing issue afterward, via "Add link → Discord message" or the
discordcommand in issue view. That's still a human remembering to do it after the fact, and the docs don't say the resulting link surfaces the message author's identity on the issue itself.
Linear's separate Customer Requests feature, which does attach a structured requester to an issue, currently connects through Intercom, Zendesk, Front, Salesforce, Slack, and the API. Discord isn't one of the listed sources, so a Discord report doesn't flow into that either without a human bridging it manually.
“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 a webhook can't just watch the channel
The instinct is to reach for a webhook that just watches the channel and fires on every new message. Discord's webhooks don't work that way. Discord's own webhook docs describe them as "a low-effort way to post messages to channels in Discord," meaning messages going in, from an external service into a channel, not out. Discord does have a newer outgoing "webhook events" system for apps, but its event list is limited to application authorization, entitlements, and lobby or game-DM activity. There's no general "message posted in this channel" event on it.
Reading messages as they're posted requires an actual bot application connected to Discord's Gateway, with the MESSAGE_CONTENT privileged intent enabled, so the bot receives message text rather than just metadata. That's a real piece of infrastructure to stand up and keep running, not a webhook URL you paste into a settings field.
A bug that got filed twice under two different names
Vantable Systems runs a public Discord for developers building on its API, and Selin Aydemir is the only person on the six-person engineering team with her Discord account linked to Linear. Every /linear issue command that comes out of that server, she runs herself.
A community member using the handle relay_kwan reported a 500 on /v1/webhooks/register any time a call registered more than three endpoints at once, working fine as of the week before. Selin filed the issue herself, titled "Webhook registration 500s above 3 endpoints," team Platform. It was created by Selin Aydemir, with no field anywhere recording that relay_kwan was the one who hit it. She typed "reported by relay_kwan in #api-bugs" into the description by hand, a habit she'd picked up after getting burned once already.
Nine days on, a developer using the handle dnt.codes described what reads as the identical failure in a different channel, in different words. Their integration was breaking overnight, they said, with 500s registering more than a few webhook endpoints at once. Nothing in that message shared a keyword with "webhook registration 500s," so nobody connected it to the open issue, and Selin filed a second one for the same bug. Both issues carried a human-typed handle buried in a description field rather than a requester Linear could match against, just text that had to be reread to be understood. When the fix shipped two weeks later, telling everyone who'd hit it meant Selin scrolling back through two issue descriptions, and she still missed a third person who'd mentioned the same 500 in a passing comment on an unrelated thread.
The DIY version: a bot, an API key, and a description field
If a human retyping the reporter's handle into every issue isn't reliable enough, the next step up is a small bot that does it for you, without buying anything new. The shape of it:
- A bot account joins the server with the
MESSAGE_CONTENTintent, watching only the channels where bug reports land. - Something has to trigger the conversion. A moderator reacting with a specific emoji works, or a slash command the bot itself registers, distinct from Linear's own
/linear issue, which still requires the caller to be Linear-linked. - On trigger, the bot calls Linear's GraphQL API directly.
issueCreatetakes a description field, so the bot writes the reporter's Discord username, their user ID, and a link to the original message straight into the issue body at creation time, instead of relying on someone remembering to add it. - Linear's docs describe two ways to authenticate that call. A personal API key works for something one person owns; OAuth2 fits anything meant to run as shared team infrastructure. Either way it's an HTTP call with a bearer token, not a connector picked from a list, since Linear doesn't publish an official app-building SDK for this specific job.
This closes the "forgot to paste the handle" failure mode completely, since the bot never forgets. It does not close the "same bug, two different names, nine days apart" failure mode, because the attribution is still just text sitting inside separate issue descriptions. Nothing reads across issues to notice that relay_kwan and dnt.codes described the same 500, and nothing lets Selin ask "who has hit this API limit, across every channel and every month" without opening each issue and reading it herself. The bot also scales with report volume, not with team size. Every report still needs a human to notice it, decide it's worth filing, and trigger the bot, and past a modest volume of concurrent reports, duplicate filings under different reporter names start piling up right alongside issues nobody has time to reread.
What closes the cross-issue gap
Modem is built for the volume the bot above can't absorb. Its Discord integration subscribes to the channels you choose, classifies every message as it lands, and clusters reports that describe the same bug into one topic even when the wording doesn't match, with every reporter who hit it attached to that topic as a real identity, not a sentence someone typed. When the topic crosses a threshold, it files the Linear issue itself, with the quotes and the full reporter list on it, and updates the same issue rather than filing a duplicate if someone else reports the same bug later. We build Modem, so weigh that against the fact that the bot above costs nothing but engineering time and holds up fine for a server where one person can read every report as it lands.
For the dedupe half of this problem specifically, how to stop the same bug from being reported in five different Discord channels covers the mechanics of catching that on the Discord side before it ever reaches Linear. The wider set of routes into a tracker, not just Linear, is compared in the best tools to turn customer feedback into Linear issues.
One rule that costs nothing to adopt
Link your own Discord and Linear accounts, and adopt one rule: every /linear issue you file for a community report gets a first line reading "reported by <discord handle> in <channel>, message link: <url>." That single habit, applied consistently, gets you most of the attribution value for zero setup cost. The bot is worth building once that habit is producing issues faster than anyone can keep straight who's on each one.
