If you run engineering in Linear and your team lives in Slack, the Linear Slack integration is one of the highest-leverage wires you can run. Done well, it surfaces the issues people need to see in the channels where decisions actually happen, lets engineers file bugs from a Slack thread without context-switching, and shrinks the gap between "this customer just reported a bug" and "engineering has a tracked issue." Done badly, it floods every channel with notifications nobody reads.
This guide is the practical version. It covers what the native integration actually does, the right way to wire it up, the small handful of decisions that determine whether it sticks, and what to do when Slack notifications stop being enough on their own. If you run support in HubSpot as well, the symmetric post on the HubSpot Slack integration covers that side of the picture.
In this article
1.
2.
3.
4.
5.
6.
7.
What the Linear Slack Integration Actually Does
The native Linear Slack integration is a two-way connection between a Linear workspace and a Slack workspace, built and maintained by Linear. It does four useful things, and most teams use only the first one.
The first is channel subscriptions. A Slack channel can subscribe to Linear events scoped by team, project, label, or status, and Slack receives a formatted message every time a matching event fires. 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, which let you 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. Most teams that find the integration disappointing are running it as a one-way notification firehose and missing the parts that actually save time.
Native Linear App vs Webhooks vs Custom
Before wiring anything up, it is worth knowing why the native integration is the right starting point.
The native Linear app in Slack is free, official, and supports two-way actions. It handles authentication, retries, and message formatting. It covers Linear's first-party events with granular scoping. The downside is that it covers Linear's event surface and nothing more.
Webhooks plus a custom Slack app handle the cases the native integration does not cover. A Linear webhook fires on every event, and a small worker can post a custom-formatted message to Slack with the exact fields and styling you want. This is what teams use when the native notification format does not fit their workflow, or when they want to aggregate Linear events with events from other systems before sending to Slack.
A full custom integration with Linear's GraphQL API and Slack's API gives you complete control and full operational responsibility. It is the right call when you have requirements that webhooks plus a worker cannot meet, and you have engineering capacity to maintain it. For most teams, this is overkill.
The honest default is: start with the native app. Add webhooks only for the specific gaps the native app does not cover. Go custom only when neither is enough.
Setting Up the Native Linear Slack Integration
Here is the setup that works for most teams. Ten minutes if you have admin access in both tools.
- 1
Install the Linear app in Slack
From Slack's app directory, install the Linear app to your workspace. A Slack admin approves it. From the Linear side, the same step lives in Settings, Integrations, then Slack.
- 2
Connect your Linear workspace
The first time the app runs, it asks you to authenticate with Linear. Connect the workspace you want notifications from. Once connected, every Slack user can link their own Linear account to use the slash command and message shortcuts.
- 3
Subscribe channels at the right scope
Use
/linear subscribein each channel to choose what fires there. The scope options are team, project, label, and status. Resist the temptation to subscribe a channel to a whole team. Scope by project or label instead, so the channel only sees events it can act on. - 4
Pick the events that matter
Linear lets you subscribe to issue created, status changed, comment added, and other events. For most channels, the right starting subscription is "issues created" and "status changed to In Review or Done." Comment subscriptions are noisy and rarely worth it at the channel level.
- 5
Train the team on capture
The slash command and message shortcuts are where the integration earns its keep. Run a five-minute demo in a team meeting showing how to turn a customer-reported bug from a Slack thread into a Linear issue with one shortcut. Most teams never use these features because nobody told them they exist.
What to Notify Slack About
The fastest way to break the Linear Slack integration is to send too much to it. Slack is good at unread badges and bad at backlog. Anything that flows through it has to be worth a human reply or a follow-up action.
A short list of notifications that earn their keep. Issues created with a specific label like customer-reported or production. Issues moved to "Needs Review" so the on-call reviewer is paged. Issues blocked or marked at risk on active cycles. Project status updates on initiatives the channel actively tracks. Comments on issues where someone explicitly tagged the channel.
A short list of notifications to skip. Every status change on every issue. Comment activity on the whole team's issues. Issues created in low-priority backlogs. Project updates on inactive or completed projects. Anything where the right reaction is silence rather than a follow-up.
The rule that scales: a Slack notification should be the start of a conversation or a decision. If the message produces no reply and no follow-up, it should not have been sent.
The Channel-Noise Problem and How to Fix It
Most teams that try the Linear Slack integration and decide it does not work hit the same failure mode. One channel collects every notification from a Linear team. The volume climbs past fifty messages a day. People mute the channel. The integration is running and effectively dead.
The fix is structural. One channel per scope, one subscription per audience.
An eng-triage channel for production and customer-reported issues
Subscribe to issues created with
customer-reported,production, orbuglabels. Audience is the engineering triage rotation. Volume stays manageable because the labels are narrow.A team channel for cycle work
Subscribe to issues moved to "In Review" and "Done" on the active cycle. Audience is the engineering team working that cycle. Notifications are scoped to what the team is shipping this week.
A project channel for cross-functional initiatives
Subscribe to project status changes and milestone updates for one initiative. Audience is the project group. Volume is naturally low because projects do not change status often.
A capture-only channel for bug intake from non-engineers
Use the slash command and message shortcut to file Linear issues from a customer-success or sales channel. The channel does not subscribe to Linear events, but it is the place non-engineers file bugs cleanly. The integration is doing inbound work, not outbound.
Four channels covers what most engineering teams need. Anything beyond that should earn its place by changing a decision. If you cannot say who replies in a channel, that channel should not exist.
When Slack Notifications Stop Being Enough
Slack is a notification layer. It is the right tool for telling a person that something happened. It is the wrong tool for storing the work that follows.
For engineering-internal flows, the integration is usually enough. Engineers see the notification, react in Linear, and the work happens. The channel and the issue stay roughly in sync because both audiences live in the same tools.
The wall most teams hit is the support side. A customer reports a bug in HubSpot. The support team needs to know the moment engineering ships a fix. The engineer working the issue does not see the HubSpot ticket. Slack is not the right place for either side of that loop to live. The Slack notification fires when the issue moves to Done, but the customer-facing reply still requires a human to write it from scratch, and the support team still has no first-class link between the Linear issue and the HubSpot ticket.
For teams running HubSpot Service Hub and Linear, the integration that closes that loop is not between Linear and Slack. It is between Linear and HubSpot. A purpose-built tool like IssueLinker creates a Linear issue from a HubSpot ticket in one click, mirrors status and comments both ways, and stages the customer-facing reply for the moment the fix ships. The Linear Slack integration still does its job for engineering-internal flow. The customer-facing side gets a real home.
The full pattern is covered in the Linear HubSpot integration guide. For teams already running Slack notifications from HubSpot, the HubSpot Slack integration guide walks through that side of the setup.
Slack tells engineering. HubSpot tells the customer. IssueLinker keeps them in sync.
If your engineering team runs on Linear and your support team runs on HubSpot, IssueLinker turns the ticket into a synced Linear issue in one click. Slack stays a notification layer. The customer hears about the fix the moment it ships.
A Quick Audit for Existing Integrations
If the Linear Slack integration is already running and the wins feel smaller than expected, three quick audits usually surface the problem.
The volume audit. Pick the busiest channel that gets Linear notifications. Count the messages from the past seven days. Count the human replies. If the reply rate is under one in ten, the channel is over-subscribed and the next step is to tighten the scope.
The capture audit. Open Slack's app analytics for the Linear app. Count the slash commands and message shortcuts triggered in the past month. If the number is single digits, the team is using the integration as a one-way notification firehose and missing half its value. Run a demo and pin a how-to in the engineering team's home channel.
The destination audit. Track what happens to the notifications that do get replies. If "support is waiting on this" gets a thumbs-up in Slack but no follow-up landed in the support tool, the bottleneck is downstream of Slack, not inside it. That is the signal that the integration has done what it can and the next step is wiring Linear to your support tool directly.