A bug gets reported in a Slack thread. An engineer says "we should track this." Someone hovers over the message, clicks "More actions," selects "Create Linear issue" - and then stares at a blank form where they have to write the title, pick the team, set the priority, and choose a project. The form still requires a human to fill in the details. Every single time.
That moment is the real story of the Linear Slack integration. The native integration is a two-way connection built and maintained by Linear - and most teams use only the first of its four features. The rest of the surface area either goes undiscovered or proves too manual to stick.
What the Linear Slack integration actually does
The four features are worth naming precisely, because most guides conflate them.
The first is channel subscriptions: a Slack channel subscribes to Linear events scoped by team, project, label, or status, and receives a formatted message every time a matching event fires. This is what most teams set up on day one and never revisit.
The second is the /linear slash command, which lets a Slack user create a Linear issue from inside a Slack thread, with the thread linked back to the issue for context.
The third is message shortcuts: turn any Slack message into a Linear issue in two clicks.
The fourth is URL unfurling, which renders Linear issue and project links inline with status, assignee, and the latest update.
The integration earns its keep when teams use the slash command and message shortcuts for capture, not just notifications. But there is a hard constraint most teams hit quickly: only Linear users in your Slack workspace can create issues with the native integration. For non-Linear users, the alternative is a feature called Asks. On a mixed team - PMs, support, design - that exclusion forces a workaround on every person who does not have a Linear seat.
The friction no one warns you about
The native integration is a good fit when issue creation from Slack is occasional and manual and notifications are enough to keep teams aligned. But it does not automatically create issues from every relevant Slack message - and that limitation is what drives teams to explore automation tools or Slack-native workflow platforms.
The deeper problem is not volume but quality. All of a conversation's context lives in Slack and none of it automatically becomes a Linear issue. Someone has to do the translation manually: copy the message, open Linear, create an issue, write the title, add context, assign it, and file it in the right project. Every single time.
If a conversation spans multiple messages, you are often creating an incomplete issue from a single message. The form captures the one line you right-clicked, not the six-message thread that contains the actual reproduction steps.
The rate limit figures above come from Linear's own developer docs. When authenticated using an API key, you can make up to 5,000 requests per hour, associated with the authenticated user - meaning all requests by the same user share the same quota even when using different API keys. For teams building custom Zapier-style automations that poll on behalf of many users through a single OAuth app, the OAuth app authentication tier drops to 500 requests per hour per user/app. At that cap, a medium-sized engineering team firing frequent webhook-driven updates can burn through their hourly budget before lunch.
How the new MCP connector changes the model
In June 2026, Slack introduced the Slackbot MCP Client. It allows developers to connect MCP servers to Slack, and once connected, Slackbot automatically discovers the server's tools and invokes them based on user prompts in conversation.
Linear shipped an MCP server for this.
A Slack admin adds Linear as a custom MCP server in Slackbot's connector settings.
Once that is done,
Slackbot can call tools to read and update Linear on your behalf: list_issues and get_issue find issues across your workspace filtered by team, assignee, project, label, status, priority, or cycle; save_issue creates a new issue or updates an existing one.
An engineering lead can ask Slackbot, "What Linear tickets are blocking our release, and are there related PagerDuty incidents active?" - and Slackbot pulls a unified view of the blocker tickets and live incidents directly into the thread, letting developers reassign tasks via interactive buttons.
That is a different interaction model than the message shortcut. The shortcut requires someone to notice a message worth capturing and remember to act on it. The MCP path lets a teammate watch a channel and surface issues proactively - or respond to a plain-language question with structured Linear data already looked up.
The MCP client respects Slack's native compliance, security infrastructure, and permission controls out of the box, and applies user-specific data boundaries in real time: if someone does not have credentials for a restricted project, Slackbot blocks the request automatically.
Beagle in action#product, 2:47pmWhat a good workflow looks like today
Most teams run a hybrid. The native integration handles the ambient layer - in the setups that work best, Slack becomes the front door for conversations, while Linear remains the place where engineering or product work is tracked. Notifications flow from Linear into dedicated channels; engineers use message shortcuts for quick captures when they remember.
The MCP connector handles the structured query layer: "What is the status of the auth refactor?" or "Which issues are assigned to me in this cycle?" get answered in thread without anyone switching tabs.
What neither path does well yet is the multi-message capture - reading a branching thread, identifying the action item buried in reply seven, and filing an issue that reflects the full context. That is where a draft-and-approve AI teammate adds the most: it can hold the whole thread in context, write a well-formed issue body, and post it for a single approval before anything touches Linear.
The practical setup that earns the most coverage:
- Channel subscriptions → one dedicated channel per Linear team (e.g.,
#eng-linear-updates), never the main#engineeringchannel - Message shortcuts → for quick ad hoc captures by Linear users
- MCP + Slackbot → for status queries and issue creation via natural language
- AI teammate with thread access → for the complex captures where context spans a full discussion
Once the integration is active, two practices prevent notification fatigue: take a separate channel, and do not push all Linear updates into your primary team channel - create a dedicated one like #product-updates where these notifications land.
Linear Slack integration: common questions
What can you do with the Linear Slack integration out of the box?
The native Linear Slack integration is a two-way connection between a Linear workspace and a Slack workspace, built and maintained by Linear.
It supports channel subscriptions for event notifications, a /linear slash command to create issues, message shortcuts to turn any message into an issue, and URL unfurling that shows issue status and assignee inline. Issue creation still requires manual form-filling.
Can non-Linear users create issues from Slack?
No, not with the standard integration. Only Linear users in your Slack workspace can create issues with the native integration. If you want non-Linear users to file issues, the alternative is Linear's Asks feature. Asks is designed specifically for inbound requests from people who do not hold Linear seats.
What is the Linear Slack MCP connector and when did it launch?
Slack introduced the Slackbot MCP Client in June 2026.
Linear's MCP server lets Slackbot read and write your issues, projects, and cycles - ask which tickets are blocking a release and it pulls the blockers into the thread; an action item from a discussion can become an assigned ticket without leaving Slack. A workspace admin connects it in Slackbot's connector settings.
Why do some Linear Slack automations hit rate limits?
When authenticated with an API key, Linear allows up to 5,000 requests per hour, and all requests by the same user share that quota even across different keys. Third-party automation tools like Zapier or Make authenticate as OAuth apps, which drops the cap to 500 requests per hour per user/app
- a tenth of the API key limit, and easy to exhaust on active teams with many issue events firing simultaneously.
Should you use Zapier or the native Linear Slack integration?
The native integration is a good fit when issue creation is occasional and manual and notifications are enough to keep teams aligned.
Zapier or Make make sense when you need conditional routing - for example, creating a Linear issue only when a message in #support receives a specific emoji reaction. The tradeoff is the 500 req/hr OAuth rate limit and per-task pricing at scale.